Federation: Neither Centralized Nor Purely P2P, but a Third Way

Social networks and chat services are usually assumed to fall into one of two camps: "centralized," where a single company runs every server, or "P2P," where devices talk directly to each other with no server at all. In between sits a third path with a history nearly as long as email itself: "federation," where independently run servers stay loosely connected through a shared protocol. This deep dive covers how federation actually works, what the Fediverse looks like in practice, and its real benefits and trade-offs.

Centralized, federated, and purely distributed: federation is not a new idea

Internet services broadly fall into three architectural categories. Centralized services are run by a single organization operating a single cluster of servers that every user connects to; this is how most web services work. Purely distributed (P2P) systems have no central server at all; user devices exchange data directly with one another. Federated systems sit in between: any number of independently operated "servers" (instances) interconnect through a shared protocol, together forming a single overall network. Users create an account on a particular instance, but as long as that instance is federated with others, they can interact with users on different instances entirely.

The essence of federation is neither "one giant server" nor "device-to-device with no server," but rather that multiple autonomous servers interconnect as peers through a shared protocol. Each instance's administrator can set their own server's policies, terms of service, and moderation stance, while still speaking the common language (the protocol) required to exchange messages and content with outside instances.

Federation as an architecture is anything but new. The longest-running federated system of all is plain email. Since SMTP (Simple Mail Transfer Protocol, RFC 821) was standardized in 1982, mail servers run by entirely different organizations (Gmail, ProtonMail, or a self-hosted server) relay messages to one another over SMTP as long as they know the destination address, user@domain. Users are free to pick whichever provider they like, yet email itself belongs to no single company.

The other prototype is XMPP (Extensible Messaging and Presence Protocol, originally called Jabber). Development of this XML-based messaging protocol began in 1999, and it was standardized by the IETF in 2004. In the mid-2000s, several chat services including Google Talk federated over XMPP, letting users of different services message each other directly. But Google shut down open federation for Google Talk (later Google Hangouts) in 2013. This episode is frequently cited as a cautionary example: a federated system can be technically viable and still be closed off by a single provider's business decision.

The Fediverse: pick an instance, federate loosely

The word "federated" is often paired these days with the Fediverse (a portmanteau of "federation" and "universe"). At its core is ActivityPub, a protocol drafted by the W3C Social Web Working Group and published as a W3C Recommendation in 2018. Any software that speaks ActivityPub can exchange follows, posts, and reactions with any other, regardless of who built it or which organization runs it. This is how Mastodon, Misskey, Lemmy, and many other services form one loosely connected network.

To join the Fediverse, a user first picks an instance (server) and creates an account there. Accounts take the form @user@instance.example, embedding the home instance the same way an email address embeds a domain, so anyone on any instance can be reached. Users can choose an instance based on interests, language, or moderation stance, and if they later want to switch, they can use account-migration tools built for that purpose.

• Local timeline: shows only posts from users on your own instance.
• Federated timeline: shows posts from your own instance plus posts that have reached it from federated instances. It is only the slice of the Fediverse your instance happens to have "seen", not a global search across every instance.
• Defederation: an instance administrator can individually cut off communication with another instance that is a source of spam or harmful content. This lets a community collectively refuse unwanted interlocutors, but it also leaves users of the cut-off instance stranded outside that part of the federation.

Benefits of federation

• Distributing operating costs: no single organization has to shoulder server costs and operational load for every user; many small, volunteer- or community-run instances stand side by side, spreading the aggregate infrastructure cost across them.
• Community-scoped, autonomous moderation: each instance's administrators can set rules and moderation policy that fit their own community, a sharp contrast to a centralized platform imposing one uniform policy on every user.
• Mitigating single points of failure and censorship: if one instance goes down, shuts down, or gets blocked in a particular country, other instances and their users carry on unaffected. It is much harder for a single company or government to shut down or censor the entire network than it is with a centralized service.

Challenges of federation

• Dependence on instance administrators: an instance's survival usually rests on the goodwill and financial capacity of a volunteer administrator. If that administrator stops running it, the accounts and posts on that instance can be lost entirely, a trade-off against the high availability a large centralized company can offer.
• Fragmentation through defederation: defederation, discussed above, is a self-governance tool for excluding harmful instances, but taken too far it can split particular instances into de facto isolated "islands," inadvertently cutting some users off from parts of the community.
• Limits on account and data portability: many implementations support migrating follower relationships, but fully migrating past posts or direct messages is generally difficult, and the cost of switching instances is not trivial.
• Re-centralization around large instances: even though anyone can nominally run an instance, in practice accounts gravitate toward a handful of large, popular instances, and network effects push things toward "federated in name, centralized in practice." Different approaches to this same problem include purely P2P designs built on a DHT where every participant holds the data, relay-based federation as in Nostr, and self-sovereign, signed repositories as in AT Protocol.

Real-world examples and comparisons: Mastodon, Misskey, Lemmy, Matrix, and email

The Fediverse's flagship, Mastodon (launched 2016 by Eugen Rochko), offers Twitter-style microblogging; Misskey, developed in Japan, offers microblogging with a distinctive UI and emoji-reaction culture; and Lemmy offers Reddit-style link aggregation and discussion boards; all three federate over ActivityPub. In text chat, Matrix achieves interoperability across many client and server implementations using its own federation protocol, distinct from ActivityPub. Each homeserver synchronizes an append-only graph of events and resolves conflicting state with an algorithm that echoes ideas from distributed consensus. Email remains the elder statesman of the group, having outlasted every other federated system covered here.

Setting aside individual implementations and comparing the architectures themselves, centralized, federated, and purely distributed (P2P) systems line up as follows.

Related pages

Federated architecture touches many of the other technologies covered on this site. ActivityPub in depth, the Fediverse's common language, turns the "interconnection through a shared protocol" described here into a concrete message format. AT Protocol in depth answers federation's re-centralization problem with self-sovereign, signed repositories and switchable relays, while Nostr in depth dispenses with the "server" unit entirely and is built from nothing but a set of relays. For the purer end of the distributed spectrum, see DHTs in depth, where every participant holds the data with no central server at all. And the mechanism by which multiple instances reconcile state without contradiction connects back to the ideas behind distributed consensus.