article Beehaw, Lemmy, and A Vision of the Fediverse

Comments

If you ask ChatGPT to summarize why Fediverse software is better than traditional social media, you might get reasons like decentralization, privacy, interoperability, or community control—and you can probably easily prioritize which of these are most important to you. In doing so, you are establishing your vision for federated software. Today, we’re going to flesh out our vision of Beehaw, and what we prioritize in our vision of federated software and the Fediverse as a whole. But we’re also going to talk about Lemmy as a software and its vision, and the critiques we have of those; the mounting evidence that suggests our vision is in conflict with theirs (and on what bases we think this is now the case); and the way forward we see for our community in light of these conflicting visions.

Beehaw and Lemmy link

One of the core goals of Beehaw is to create a nice space on the internet. When we joined Lemmy a little over two years ago, we saw it as a good fit for that–making our own platform and getting it right required an amount of time and energy that we couldn’t commit to. Lemmy also had many of the features of community control we were looking for while simultaneously connecting us with other communities through federation. But Lemmy is not perfect. Particularly since June of 2023 the rapid growth of our community, and the surrounding nebula of federated communities that have joined us here, caused some growing pains and exposed new issues that we’ve talked about a lot on here, on Discord, on Matrix, to other Lemmy admins and volunteers, and of course to the Lemmy developers themselves.

We’ve done a lot to try and mitigate or fix those growing pains. We’ve attempted to coordinate new features, particularly mod tools that we think would help instance admins; we’ve submitted PRs and bugs while also busy running our own site; and one of our admins helped organize the Github and categorize all the requests being made because the Lemmy developers are juggling so much else. While we’ve obviously not been perfect, we’ve likewise done our best to suggest and submit ideas or changes in ways which make things as painless for the developers as possible. In our early interactions we attempted to interface directly with them whenever possible. In cases where it’s been ambiguous what to do, we double check what they want - in one such case we ran the idea of code bounties for getting mod tooling developed (they told us not to do this, and we obliged). On Matrix we organized a channel for admin coordination and deferred to a Lemmy-developer led organizational channel. There, we heard out their request to structure our mod tooling ideas as a request for comment.

This is all to say: we’ve been given many different channels and suggestions by the developers during our time on this platform for how to influence priorities. However, those priorities still have not materialized even after we used those channels and followed those suggestions–in fact, we’ve often observed our priorities seemingly being derided, played down at times, or left to languish. Increasingly, it has become evident that our suggestions are viewed as some sort of attack or criticism of the Lemmy developers. In fact, an interaction with the Lemmy developers recently culminated in being told quite unambiguously that we should leave the platform and that our priorities are entitled:

It should go without saying: we disagree strongly with this treatment, we contest the idea that these are “demands,” and we believe the Lemmy developers were acting severely out of turn here. (It would also appear that, at least for a time, some of our comments were removed and several of us were banned from their instance–although this may now be overturned.)

But there are many kernels of truth in their frustration. There are not infinite resources to go around. Working on Lemmy has always required a degree of sacrifice to their personal finances and time and there is a need for developers to prioritize development across a number of axes. We do not have an issue with that and we feel that we’ve done what we can to help them keep this ship afloat. In our view, the underlying disagreement here is philosophical in nature, not interpersonal: we believe what is happening here is a mismatch in vision for the software. (And, to be up front before we illustrate what we believe are the mismatches here: this is not to say that their approach is wrong or bad, or that ours is right or good.)

Contrasting philosophies? link

We pride ourselves on having a thought out, strong, unambiguous mission and series of beliefs that guide Beehaw–it’s a reason why we put our mission statement up front and we have a comprehensive set of documents detailing our philosophy. We think that transparency around our actions as well as our thoughts helps to build trust and keep us accountable. We want to demonstrate and promote a healthier environment, and we think moderation is a key feature of ensuring that. But our mission statement seems to be strongly at odds with, for example, the Lemmy devs arguing against the removal of transphobic or racist instances on the join-lemmy homepage. Certainly it becomes harder to sell people on our space being what we claim it is when the developers dismiss concerns that instances featuring this kind of bigoted speech being advertised up-front might turn away minorities, queer people, or anyone else looking for safer and nicer alternatives to mainstream platforms.

In fact, these posts might prompt people to ask why we even use this platform–and at one point we wrote an essay defending being here in which we noted that “[…]it’s just not a particularly fruitful discussion to zero in on whether the political leaning of the main developers and instance are in perfect alignment with what we want to accomplish. We are not explicitly endorsing their viewpoint by using their software and we are not tied to using this software forever.” We stand by that sentiment. In that essay, though, we also wrote that “We think we’ve done a decent job outlining what we intend to do with this instance and explicitly made strong stances against hate speech[…]” and we have reason to believe this sentiment isn’t shared completely by Lemmy’s developers.

When we first set up on Lemmy, people warned us that its developers had a very different vision for Lemmy as a platform than us. We did not feel like this was an insurmountable issue; we were optimistic that these tools would mature in our time here. We were even told, by central voices like nutomic, that admins should have a seat at the table: "[…]I definitely think that admins are the main actors who should have a voice in development.", and, to not belabor the point, we agree with that and we have tried to express our voice in development accordingly. Unfortunately, it would seem that we, and our priorities, have now been completely written off as entitled–even as other Lemmy administrators make some of the same points as us.

Our vision on the need for moderator tooling is not just about hate speech or providing a safe space for minorities. It extends to other issues: CSAM, or child sex abuse material, is one such case. CSAM presents a unique problem for nearly all federated services–it’s arguably a downside of federation–and Lemmy is not an exception. In August 2023, lemmy.world was attacked with multiple CSAM images, a situation that quickly cascaded into a Lemmy-wide crisis because of federation. Admins found themselves lacking a suite of mod tools to handle the situation, lacking features that would allow them to easily comply with the law, lacking any ability to pre-empt such attacks to begin with and found themselves scrambling to implement ad-hoc solutions such as Fedi-Safety to deal with this. At least one community (lemmy.online) outright shut down rather than assume the liability of future CSAM attacks.

But the Lemmy developers, both then and now, seem to lack the same urgency that instance administrators do on this matter. They were fairly slow to acknowledge what was happening–and when they did, they responded in a way that can only be described as insensitive. On Issue 3920, made at the peak of the crisis, Lemmy developer Dessalines infamously replied to one proposal for handing CSAM with “Adding an image-upload moderation queue is not something we have time for rn.”. That comment has since been rescinded, but the relaxed attitude it expressed remains in place. As recently as a few days ago Lemmy developer nutomic stated that “Correct the CSAM wave was handled by admins on their own. As far as I remember there were no specific feature requests that would have helped in this regard, and anyway they would have taken too long to implement and publish.”. But this was not the first time CSAM was posted on Lemmy, nor the first time federation of problematic images caused problems for instance owners - nutomic and dessalines have a history of trolls posing as them and spamming instances with scat porn, for example. In addition, issue 3920 itself is full of specific feature requests or suggestions to solve the CSAM attack and many of the tools and changes we’ve advocated for since landing on Lemmy would have been useful here. The available evidence, overall, stands in sharp contrast to the statement that no feature requests would have helped. It seems to imply, in the view of the Lemmy developers, that the onus remains entirely on administrators to preempt or manage another CSAM attack.

To be clear, we do not challenge the premise that what they prioritize is their right–this is their software, and they have great say over what happens and what does not. What was–and still is–being asked of them would also take effort between the two of them. But, as people liable for hosting what is posted by our users, you can perhaps understand why we are very uneasy philosophically with putting this issue on the backburner or being left to handle it ourselves with the tools we do have. These tools (more accurately, the lack thereof) currently mean every instance administrator, ourselves included, are exposed to much more liability (and objectionable material) than necessary. It seems largely through luck–and to a lesser extent ad-hoc solutions–that no other known CSAM attacks have taken place on Lemmy.

No doubt there are other points of friction too, but we think these two examples suffice for illustrating differences of perspective. We turn then to the question of: what is our philosophy and, if there is a philosophical difference here, what is to be done?

Vision for the Fediverse and looking forward link

Our examples here help to frame fundamental questions of one’s vision for the Fediverse. Who should have a say in the structure or function of a federated software? What mechanisms for participation should exist for a software’s communities? Where should the limits be for moderation and moderation tooling, especially with limited resources? Is it the place of a software provider to intervene if their software is being used harmfully? All these and more are very important questions to consider in presenting a vision of the Fediverse–and while we don’t claim to have every answer, we’ve spent a lot of time thinking about these questions.

Vision, we assert, is important to answering these questions and defining the philosophy of a piece of software. Even if it is never written down anywhere, we believe vision is always present. Take, for example, the ability to block individuals or content: the determination of who gets this power and what things can be blocked are both matters of vision. Someone who is strongly pro-free speech may object to the very feature of blocking. Someone who defines the health of the Fediverse by connections between instances may believe that only users, and not instances, should have the power to block content. Vision directly shapes implementation. It outright determines not only the prioritization of a feature or a request, but whether that feature or request can exist (or coexist) as a part of the software it’s proposed for. In kind, implementation shapes outcomes. To not allow users to block each other may be closer to free speech and to not allow an instance to block another instance may be healthier for the Fediverse, but both choices make harassment trivial and reduce or remove tangible penalties for toxic behavior.

Vision, then, is the reason we believe admins should have input on Lemmy priorities. It’s the reason we disagree with many of the positions and priorities expressed by the Lemmy developers. And it’s the reason we believe in granular controls for federation, strong moderation tools, registration sign-ups, and similar functionality. We think our vision and its implementation allows us to create a safer space online that lives up to our philosophy. We also think it allows for a healthy, pluralistic Fediverse in which users can move between legitimately distinct communities as their needs arise. But many people don’t agree with that vision for one reason or another, and that seemingly includes the Lemmy developers as we’ve talked about at length here. And even granting the unlikely idea that our priorities will still be implemented one day, having the developers actively hostile towards us is itself problematic. So what can we do?

In all probability: the way forward is off Lemmy. This is not a commitment to doing that, but we consider it very unlikely that the Lemmy developers are willing to work with us going forward—after all they explicitly told us to leave. However, a large part of our community exists because of Lemmy, and we certainly wouldn’t want to lose members of our community just because our vision apparently diverges from that of the developers. As we talked about several months ago in Beehaw on Lemmy: The long-term conundrum of staying here, we’ve been exploring alternatives—and today, while we’re still not ready to commit to a jump, we’re a lot more confident in our ability to leave Lemmy but stay federated and better execute our vision. Speaking of which- keep your eyes out for a community poll in the days to come about this subject and what features are important on any platform we choose besides Lemmy.

As a final point, we think this sort of community involvement—facilitated by Fediverse tools or otherwise—is particularly valuable for what we’re doing here and for our vision for the Fediverse. Most of what we consider a prerequisite for a community such as ours involves more participation from users, whether that comes in feedback, in advising site direction, or in helping to uphold our philosophy. We are, for instance, often surprised by how little moderation is actually necessary on Beehaw against Beehaw users. It’s clear that the community has bought into our vision and we’re glad that’s the case. Take the wonderful, nuanced discussion about the ethical merits of voting for Joe Biden within this community: that discussion elsewhere could have been nasty, fraught, or just impossible to have. But we should also take care. Evaporative cooling can rapidly occur if these discussions are poorly moderated and we could easily become a train station in which such discussions are closer to the replies under a tweet than familiar faces around a dinner table. It’s quite easy for us to see a future where, without controls like the ones we have been advocating for, such discussions become unmanageable as Lemmy grows because of those outside the community.

And that’s why we speak so much on these subjects and at such length. Better communities and better worlds do not come about on their own—people build these communities, and they must have the right tools to build them and maintain them with. We think our case for what those tools are, why we consider them necessary for Beehaw to be the best that it can be, and our broader vision surrounding their place in the Fediverse has been made. If you find that case persuasive, then we hope you will follow wherever our situation takes us.