Skip to main content


So… I've seen several people lately arguing that Bluesky is a fediverse network, on the premise that interoperability between independently-run instances is enough to qualify. But I think that misses something fundamentally distinct about the fediverse—namely: federation. Which is a particular social relation, structurally analogous to political federation: autonomous, mostly self-governing states, mutually deciding to associate in a united network.
in reply to L. Rhodes

ActivityPub is built around federation. One of the assumptions of the spec is that services that use it will establish structural relationships to one another by federation, uniting their populations in a common network. Defederation, as much as we bicker over it, actually serves as a pretty good litmus for whether a service fits in the fediverse—if you can't break ties with an entire service, then you're probably not fediverse.
in reply to L. Rhodes

For better or worse, federation is a social structure that shapes the fediverse. It conditions what interoperability means on the network, and informs how we communicate across it in ways that aren't always entirely clear to us even as we do it. I'm not suggesting that you have to buy into social media federalism as a philosophy or a political stance, but it's one of the technical underpinnings that define the social part of social media in its fediverse incarnation.
in reply to L. Rhodes

You can have decentralization without federation. Imagine, for example, a network of independently run servers that are effectively locked open so that intercommunication is involuntary. Maybe there are ways to get around that—blocking an IP on the server firewall, for example. But that's not an affordance built into the service; it doesn't mean our hypothetical protocol is designed to structure relations around federation. It's a workaround for a system that doesn't provide for defederation.
in reply to L. Rhodes

Is Bluesky federated? That's debatable. Bluesky is designed to be (mostly) decentralized. It's similar to AP services in that individuals can run their own account servers, hosting other people. But the primary structural relation that connects those servers is not federation. Most communications pass through multiple other services, some more decentralized than others, before they arrive at their destination, and their point of origin may be obscured in ways that aren't possible here.
in reply to L. Rhodes

In a lot of ways, ATproto looks like it was designed to resist federation. Messages are pull rather than push. Account handles are decoupled from their host domains. Moderation is partially abstracted from hosting. There seem to be multiple avenues for routing around local moderation. Autonomy, self-governance, mutual association—each of those seem diminished by those structures, at least in comparison to the affordances built into ActivityPub.
in reply to L. Rhodes

So I wouldn't call Bluesky federated. If you wanted to insist on calling it federated, I think you would need to qualify the term, at the very least. "Indirect federation," or some such. But if you like Bluesky, or you're interested in its potential, I think you'd do better to choose a description that highlights the specific things it seems designed to achieve, and federation doesn't really capture that.
This entry was edited (2 months ago)
in reply to L. Rhodes

Account portability, composable moderation, decoupling the "speech and reach" layers—a lot of the design features that distinguish ATproto from AP are concentrated around giving individuals the maximum amount of autonomy from one another. In many ways, it strikes me as a radically libertarian social structure, but I don't suppose everyone will prefer to frame it in those terms.
in reply to L. Rhodes

(Libertarianism is one thread driving Bluesky development. Another is commercial profit, centered on the challenge of structuring a protocol to serve Big Data monetization. ATproto has taken shape around the points where those two threads converge—e.g. the way they've structured portable identity not only makes individual accounts harder to govern, it also gives users permanent, stable identifiers that are easier to track no matter how often they migrate to new hosts.)
in reply to L. Rhodes

None of which is to say that fediverse-style federation is necessarily superior to the structural relations that define Bluesky. I'm sure some of your reading this see the appeal of what ATproto is built to afford. The point is that they ARE, in substantive ways, different, and that reducing them both to fediverse obscures one of the most fundamental of those differences—not just in arguments about interoperability between them, but also simply for assessing the operations of each.
in reply to L. Rhodes

Bit of a post-script: I don't think it would be unfair to characterize the way Bluesky structures relations as "anarcho-capitalist."

"Anarcho" in view of the radical autonomy it strives to give individual users on the network.

"Capitalist" in that the organization of the basic functionality around costly indexing servers makes capital accumulation essential to the operation of the network as a whole.

Anarchocapitaliverse is a mouthful, though. Gotta be a better name than that.

in reply to L. Rhodes

This article presents a pretty interesting example of how people's relative familiarity with Mastodon leads us to describe Bluesky in terms of federated decentralization, even when that's misleading: https://techcrunch.com/2024/02/14/bluesky-and-mastodon-users-are-having-a-fight-that-could-shape-the-next-generation-of-social-media/

Federated decentralization can, in fact, lead to separate networks, as happened here when our part of the fediverse mass defederated from far right servers. You'd have to stand up an entire second infrastructure to make ATproto work that way.

This entry was edited (2 months ago)
in reply to L. Rhodes

So given all of the above, does #Threads qualify as fediverse? Certainly not yet, but how about once it rolls out full "interoperability"? The honest answer is: I don't know. If they had launched using AP natively, I'd say "yes" outright—not that using AP is a requirement for federation, but embracing AP signals an embrace of federation as a structural relation. The devil is in the details, but what Meta has talked about so far sounds a lot like federating with AP-based servers, so maybe.
in reply to L. Rhodes

Let me take another stab at putting a name to the differences…

A network where direct exchange between autonomous peer servers is governed by (at least tacit) mutual agreement is FEDERATED.

A network where exchange between peer servers passes indirectly via a non-peer third party is MEDIATED.

Fediverse is federated. Bluesky is mediated. (Mediverse)

This entry was edited (2 months ago)