Bluesky is having A Moment right now, and my feed is getting busier with games industry folks. It’s lovely! I’m a little sad Mastodon didn’t get the same love but Bluesky is undoubtedly easier to use.

At the same time, another challenger social media platform is having a different kind of moment. Cohost is being shut down - the creators are understandably unable to sustain funding for it.

I didn’t use Cohost much but it seemed great. Communities being lost is always sad. The survivability of online spaces is therefore very much at the front of my brain this week, and while it’s highly inconsiderate to tell those mourning Cohost that centralisation was their core problem it is, nonetheless, partially true.

If we build a new community on Bluesky, how likely is it to die? How could it be saved? What are its extinction events, and how can they be mitigated?

To answer these questions we need to look at federation, at the Fediverse, at how Bluesky’s underlying technologies work and how those intersect with the push and pull of human beings. It’s a rabbit hole. Let’s dig.

What is the Fediverse?

“The Fediverse”, or “Fedi” to its close friends, is a term rather like “the web” that is quite hard to define without getting into rules and exceptions.

The most common definition seems to be “a network of instances of software that talk to one another via the ActivityPub protocol”. This is the one you’ll see most often and is the one Fedi people mean when they talk about Fedi. They mean Mastodon, Pleroma, Pixelfed, Lemmy, and many more.

However, there are often exceptions made to this rule that make “the Fediverse” much less clean-cut. Threads, for example, can communicate via ActivityPub (in a publish-only fashion at the time of writing) but is usually considered separate to, or a threat to, the Fediverse. Diaspora has its own protocol, but usually is considered part of the Fediverse, as are other protocols within the lineage of ActivityPub such as OStatus.

¹ via Wikimedia Commons

Complicating this further is the use of bridge software like Bridgy Fed, which can translate between protocols so that users on Bluesky can talk to those on Mastodon.

My view is that most definitions of “Fediverse” are unhelpful. Instead it might be better to look at it not as a list of technologies but as a measure of how easily it can be killed.

The exinction event for Cohost was running out of money. The exitinction event for Twitter, albeit a slow ongoing one, was a buyout by a fascist billionaire.

The extinction event for the Fediverse is rather harder to define. An individual Mastodon instance might go dark or a project lose a maintainer, but the network itself is remarkably resilient. This is rather like the web! The Fediverse’s predators are still out there, though are rather larger and more nebulous. Perhaps a coordinated embrace-extend-extinguish attack could decimate its userbase but even in that case there’d inevitably be a few instances hanging on to The Old Ways.²

Friendica has been around nearly as long as Twitter. I don’t know anyone who uses it, but it has a community, and as long as someone is running an instance somewhere it is basically unkillable. One might as well ponder how to destroy email, though I gather Google is making a spirited attempt.

These extinction events are terrible for the preservation of information and culture, and, perhaps more importantly, are devastating for the communities that emerge in online spaces.

This brings us to Bluesky.

Bluesky and federation

Federation on Mastodon can be understood as simply as “there are instances and they talk to one another, or don’t”. Of course, the definition of what a Mastodon instance actually is is surprisingly complex in terms of components, but viewed at a network level it’s actually a fairly good model.

Bluesky is a bit more complicated. There’s a really good blog post showing their proposed federation model, and it includes this diagram:

This looks scarier than it is.

• A PDS (Personal Data Server) is somewhat close to Mastodon’s idea of an instance. It stores data, handles user accounts and login, and generally coordinates your presence in the network³.
• A Relay is a big chonky service that consumes updates from all the PDSes it knows about and turns them into a firehose stream.
• An AppView consumes the updates from the Relay and renders them into a format that a client can reasonably make use of. How it does this is very dependent on the application; Bluesky is considered to be just one Lexicon in the network.
• Feed generators and Labellers are separate services that host custom feeds and account labels respectively. These are starting to pop up a lot, they’re really neat.

You can think of a Mastodon instance as a PDS and AppView smooshed together⁴. The idea is that the AppView and PDSes will have rather different scaling characteristics; I can attest to this as even running my single-digit-user-count Mastodon instance costs around $20 a month.

PDSes are open to federation now; there’s an example on GitHub and I know several people who’ve done it. Working with AT Proto is really nice, as I discovered.

Moderation on Bluesky is also federated. Labellers plug in to the Bluesky AppView and are used to label content. The user’s client can then set what it does or doesn’t want to see. The idea is you’d subscribe to the labellers that you trust to moderate things appropriately for you. This decoupling of moderation from data storage means you’re less exposed to the “forum admin mad with power” problem that Mastodon sometimes gets.

However, defederation on Mastodon is a very powerful tool. There’s a reason nobody sees Truth Social posts on their feed, despite it being technically part of the Fediverse.

Bluesky aims to combat this by having centralised moderation within the Bluesky AppView. Their labellers are applied to all posts that pass through, it’s not something users can unsubscribe from. This is important, but it’s also a point of vulnerability. Let’s talk about that.

The fascist billionaire problem

Bluesky is a private company with investors. Twitter was a private, then public company, and since the buyout is now private again. Mastodon gGmbH is a non-profit company. Having a source of funding allows these projects to grow more quickly, but there’s an issue of power, and it’s important to distinguish between power over the software and over the network itself.

When Elon Musk bought Twitter he gained full control over the product and its entire network; in a centralised service the two are synonymous. Eugen Rochko could go full fash tomorrow and while this would be a setback for the Fediverse it would not really damage the network itself. Even if development on Mastodon entirely ceased - unlikely given its license, there will always be forks - some other project like Misskey or Pleroma would fill the gaps.

Bluesky, as it is right now, exists in a strange middle ground. If the company was taken over by a bad actor the network itself could continue to function - AT Proto is an open protocol - but because the AppView is a point of centralisation and is not, to my knowledge, open-source, I’m not sure how feasible it would be to have Bluesky without Bluesky Social. The relay isn’t open-source either and I’m not aware of any independent ones running; at minimum it would be very expensive to do so.

Update 2024-09-14: Thanks to this HN comment for pointing me to an open source implementation of the relay, as well as a blog post about costs.

The relay problems are probably solvable given time - Bluesky themselves do say their architecture is not prescriptive - but ultimately that Bluesky AppView is a point of vulnerability in terms of power over the network as it exists today. A central point of control is useful in moderation terms - Bluesky will hopefully have a bare minimum level of decency as a global community - but if that moderation can be subverted that becomes a problem. Like deciding “cisgender” is a slur.