A federated social network is a group of independently run servers that speak a shared protocol, so users on one server can follow and interact with users on another. No single company owns the whole network.
The best-known federation is the fediverse, and this guide explains the mechanics behind it in plain terms.
How a federated social network works
A traditional social service keeps everything on servers run by its owner. According to Wikipedia’s Fediverse entry, the decentralized structure of the fediverse “allows any individual or organization to host a social platform” of their own. Each server is called an instance, and each instance has its own accounts, rules and administrators.
What makes the set of instances a network is that they exchange messages. Wikipedia compares it to email: much as users of one email service such as Gmail can still send emails to users of another service such as Outlook, users may still view content and interact with users on any other instance in the fediverse.
In practice, a person signs up on one instance and gets an address made of a username and a server name. Following someone on a different instance tells the two servers to deliver posts, replies, boosts and likes between them. The person never needs a second account.
The role of the ActivityPub protocol
Federation depends on a common language. The same Wikipedia entry says most fediverse platforms are based on free and open-source software and create connections between servers using the ActivityPub protocol. Without a shared protocol, servers would be isolated islands.
The standard has a short history. In January 2018, the W3C presented ActivityPub as a recommended standard. It aimed to improve interoperability between different software packages running on a wide network of servers, and to supersede both the OStatus protocol and Pump.io. By 2019, almost all software that had been using OStatus had added support for ActivityPub.
Some software still supports older federation protocols as well, such as OStatus, the Diaspora protocol and Zot. Diaspora is described as the only actively developed software project of the original fediverse definition that does not support ActivityPub.
Different platforms, one network
Federation is not limited to one kind of app. Different services can talk to each other as long as they share a protocol. Wikipedia gives an example: a user on the microblogging platform Misskey may view and interact with posts made by users on Mastodon.
The same holds across formats. A user on a social news instance running Lemmy can interact with a post from an instance of mbin, a similar service, and with microblog statuses from Mastodon. The mastodon platform is the most familiar microblogging example, while video hosting is covered by peertube.
Federated versus centralized and peer-to-peer
| Feature | Centralized network | Federated network |
|---|---|---|
| Who runs the servers | One company | Many independent operators |
| Accounts | One account per service | One account on any instance, reaching the others |
| Rules and moderation | Set by the owner | Set by each instance |
| Leaving | Content stays with the platform | Depends on the software; users can usually choose another instance |
The comparison summarizes the design differences described in Wikipedia’s Fediverse entry.
Federation sits between a fully centralized service and a peer-to-peer system with no servers at all. Users still depend on a server, but they can choose which one, and no single owner controls the whole network.
Moderation and defederation
Federation changes how moderation works. Wikipedia notes that moderators are responsible not only for content posted by users of that instance (“local users”), but also for content posted by users of other instances (“remote users”).
There is also no central authority. Because there is no centralized governance or moderation, it is impossible for an instance to be “removed” from the fediverse. An offending instance can only be defederated, which happens when other operators choose to make its content inaccessible from their instances. Each instance defines its own content policies, enforced by its staff.
For users, this means the choice of instance matters. Its rules, its moderators and the other servers it blocks shape what the person sees day to day.
What federation does and does not guarantee
Federation spreads control across many operators, but it does not make every instance identical or every experience seamless. Each server runs its own software version, its own settings and its own policies. Features that work well between two instances of the same application may work only partially between two different applications, because each application decides which parts of the shared protocol it supports and how it displays them.
The protocol also does not guarantee that every post reaches every server. Delivery depends on instances being online, on operators not blocking one another, and on users choosing to follow accounts elsewhere. A new instance starts with an empty view of the network and fills it as its users follow people on other servers. Content from remote instances appears locally mainly because someone on the local server has an interest in it.
Federation also does not remove the need for trust. Administrators can read what is stored on their servers, so the operator of an instance is a real party in the relationship. Choosing a well-run instance with clear rules and a reachable administrator is the practical counterpart of choosing a reliable email provider.
Choosing an instance
Because the network is made of many servers, newcomers face a choice that centralized services never ask for. A few practical questions help narrow it down:
- Who runs it? A server maintained by an individual, a club, a non-profit or a company each carries different expectations about longevity and funding.
- What are the rules? Content policies are written by each instance, so they differ on topics, language and tolerance for particular kinds of posts.
- How is moderation handled? Active moderators matter, since they deal with both local and remote users and decide which other instances to block.
- What is it for? Some instances are general-purpose, while others serve a region, a language or a shared interest.
Since an account on one instance can reach people on others, the first choice is not permanent in the way a platform sign-up is. Users who later prefer a different server can usually create an account there and follow the same people again, although the exact steps for moving content depend on the software involved.
Why the design matters
The main practical effect of federation is that no one party can switch the whole network off, change its rules for everyone or decide who may take part. A single instance may disappear or be blocked by others, but the network as a whole continues. That resilience comes from the same feature that makes moderation harder: authority sits with many operators rather than one.
It also changes how new services appear. Because the protocol is open, a developer can build an application for video, microblogging, link sharing or events, and that application can exchange content with others without negotiating access to a central platform. This explains why the fediverse includes so many types of software that still interact with one another.
The trade-off is complexity. Users must understand that there are many servers, operators must handle moderation of content that arrives from elsewhere, and developers must keep up with how different projects interpret the same protocol. Those costs are the price of a network that no single company owns.
Frequently asked questions
Is a federated social network the same as a decentralized one?
Not exactly. Federation is one form of decentralization, where many servers interoperate through a shared protocol. Wikipedia describes the fediverse’s structure as decentralized, with each instance run independently.
Do users need an account on every instance?
No. One account on one instance is enough to view and interact with users on other instances, much like email between different providers.
Can different apps interact with each other?
Yes, when they share a protocol. Misskey users can interact with Mastodon posts, and Lemmy users can interact with posts from mbin and with Mastodon statuses.
Can an instance be banned from the whole network?
No. There is no central moderation, so an instance can only be defederated by individual operators who choose to block it.
