A decentralized social network is a set of independently run servers that speak a shared protocol, so people on different servers can follow and message each other without any single company owning the whole network.
It is the core idea behind every open source social network, and the details differ by protocol.
Centralized versus decentralized: the basic difference
A traditional social service hosts all content on servers managed by one owner. Accounts, posts, rules and the algorithm all live in one place, and leaving means leaving your audience behind.
A decentralized design splits those roles. Anyone can run a server, each server holds its own users’ accounts, and servers exchange posts using an agreed format. The result feels like email: an address on one provider can still write to an address on another.
The term “decentralized” covers a spectrum. Some systems federate, with many medium-sized servers. Others separate identity, storage and feeds into layers that different operators can run. Both avoid a single point of control, but they distribute power in different ways.
How federation works
The best-known family is the Fediverse. The word is a portmanteau of federation and universe, according to Wikipedia’s Fediverse article, which also says most platforms in it are free and open-source software that connect servers using the ActivityPub protocol.
In practice, each server is called an instance. A person signs up on one instance and gets an address such as a username plus the server’s domain. When that person follows someone elsewhere, the two servers exchange messages directly. Posts from the followed account are delivered to the follower’s home server, which shows them in a timeline.
Different apps, one network
Because the protocol is shared, different software can interoperate. A Misskey user can view and interact with posts made by Mastodon users, and a Lemmy user can interact with posts from mbin instances as well as Mastodon statuses, per the same Wikipedia article. Software built for photo sharing, link aggregation or microblogging can sit in one social graph.
Some projects still support older federation protocols such as OStatus, the Diaspora protocol and Zot. Diaspora is described as the only actively developed project in the original Fediverse definition that does not support ActivityPub.
Following a post from one server to another
A concrete example shows the mechanics. Suppose one person is on a small server run by a hobbyist group, and a friend is on a large general-purpose server. The first person follows the friend by typing the friend’s full address into a search box. The home server looks up that address, finds the friend’s server, and sends a follow request. Once accepted, every new post from the friend is pushed to the follower’s server and stored there, so the timeline loads from a nearby copy instead of fetching from the other side each time.
Replies work in reverse. A reply is created on the replier’s server and delivered to the server of the person being answered, which is why a conversation can look slightly different from one instance to the next. Each server shows only the parts it has received, and an instance that blocks another will never receive that side of the discussion.
This design explains many everyday quirks. Follower counts can differ between servers, an old post may appear late if a server was offline, and a deleted post can linger briefly on servers that have not yet processed the deletion.
A different model: the AT Protocol
Not every decentralized network federates this way. Bluesky is built on the AT Protocol, which splits the system into layers. Its documentation names three core services: Personal Data Servers, Relays and App Views.
- Personal Data Server (PDS): holds a user’s data repository and account.
- Relay: according to the AT Protocol overview, relays collect data updates from many servers into a single firehose.
- App View: builds the timelines and views that users see from that firehose.
Identity is handled separately. Users have permanent decentralized identifiers (DIDs) for their accounts, plus a configurable domain name that acts as a human-readable handle. Because the identifier is permanent, a person can in principle move servers without losing their account identity. The docs also note that feeds, labelers and search indices can be provided by independent third parties.
Why the layered approach matters
Splitting storage, aggregation and presentation means no single operator has to run everything. A small group can host a PDS for friends, while a separate organisation builds a custom feed or a moderation labeling service that users opt into. Competition can then happen at the feed or label layer rather than only at the whole-platform level.
The cost is complexity. Running a relay or App View involves processing a large stream of updates, so in practice many people rely on a few large operators for those layers even though the design allows alternatives. A network can be decentralized in its protocol while still being concentrated in how people actually use it, and readers evaluating any system should look at both.
Moderation in a decentralized social network
Decentralization changes who enforces rules. Wikipedia notes that decentralized platforms bring new challenges for user trust and safety. With no central governance, an instance cannot be removed from the Fediverse; an offending instance can only be defederated by other instance operators’ choice to make its content inaccessible from their instances.
Each instance sets its own content policy, enforced by its own staff. That gives communities control, but quality varies by operator. Choosing a server therefore means choosing its moderation, its funding model and how long it is likely to run.
Users also have tools of their own. They can mute or block individual accounts, and a person who dislikes how a server is run can usually create an account elsewhere and follow the same people from there. Moderation is therefore layered: the user, the server operator and, on some networks, independent labeling services each contribute a part, and none of them can speak for the whole network.
These trade-offs matter for people weighing a open source twitter alternative, since the experience depends on the server and protocol chosen, not only the app.
Practical trade-offs for new users
- Choice: several apps and servers exist, but newcomers must pick one first.
- Portability: the protocol decides how easily accounts and followers move.
- Resilience: no single shutdown ends the whole network, though an individual server can disappear.
- Data exposure: posts are copied across servers, so deletion and visibility depend on each operator. Readers focused on this should consider privacy-respecting social options and read each server’s policy.
Questions to ask before choosing a server or app
- Who runs the server, and how is it paid for?
- What are the posted rules, and how are reports handled?
- Does the software use ActivityPub, the AT Protocol or another protocol, and what does that mean for moving later?
- Can the account be exported, and are followers carried along?
- Is the code open source, so that the community can inspect and fork it?
Answering these takes a few minutes and avoids most of the frustration new users report, such as joining a server that later closes or finding that its moderation style does not fit.
Barnraiser.org is an independent, non-commercial site. It is not affiliated with any project or platform mentioned here, sells no hosting or software, and uses no affiliate links.
Frequently asked questions
Is the Fediverse the same as a decentralized social network?
The Fediverse is one example. It connects servers mostly through ActivityPub. Other designs, such as the AT Protocol, are also decentralized but divide the work differently.
Who controls a decentralized network?
No single party does. Each server operator controls their own instance and its rules, and operators can choose to block, or defederate from, other instances.
Can users on different apps talk to each other?
Often yes, when the apps share a protocol. A Misskey user, for example, can interact with Mastodon users.
What is a handle in the AT Protocol?
It is a configurable domain name acting as a human-readable name, while a permanent DID identifies the account underneath.
