
Guides
What actually changes about leaving a decentralized network?
Decentralized networks explained by mechanism: what federation genuinely changes about removal and exit, and what it leaves exactly as it was before.
Decentralized networks are described more often than they are explained. The claims made for them are large and the mechanisms behind those claims are small and specific. This page separates the two: what changes structurally when a network is federated or protocol-based, and what stays exactly the same as everywhere else.
The short version: decentralisation changes who holds the power to cut you off, and it changes almost nothing about the difficulty of the work that power is used for.
What to take away
- If the appeal is not being subject to one company's unilateral decisions, decentralisation delivers that, and the cost is discovery, some operational responsibility, and a smaller audience.
The three architectures people mean
Centralized. One company runs the servers, defines the rules, holds the accounts, and controls distribution. Everything described in the notes on large general-purpose services.
Federated. Many independent servers run compatible software and exchange messages using a shared protocol, which is what federation means in this context and nothing more. Your account lives on one server, operated by whoever runs it. That operator sets your rules, holds your data, and can suspend you, but they cannot cut you off from the rest of the network, because the rest of the network is not theirs.
The common example is ActivityPub, the protocol that Mastodon and most servers in that network speak.
Protocol-based with portable identity. A step further: the identifier that represents you is designed to be independent of any single provider, which is the problem the W3C decentralized identifier specification sets out to define, so that in principle you can move providers and keep your identity and your followers. Whether this works in practice depends on how the identifier, the data store, and the discovery layer are actually implemented, which varies and which is worth checking directly rather than assuming.
Bluesky's AT Protocol is the best known current attempt at this.
Most arguments about decentralization are really arguments between the second and third of these, conducted in the vocabulary of the first.
What genuinely changes
Moderation becomes plural, not absent. This is the most misunderstood point. Federation does not remove moderation; it multiplies it. Each server sets its own rules, and servers additionally decide which other servers they will exchange messages with. The practical result is that there is no single appeal, no single policy, and no single body that can remove someone from the network entirely. For people who were unfairly removed from a centralized platform, that is a real improvement. For people trying to get harassment stopped, it is often worse, because the person harassing them is somewhere the moderator has no authority over, and the only available remedy is a blunt one: blocking an entire server.
Exit stops being catastrophic. On a centralized service, leaving means losing everything. On a federated one, moving servers is a defined operation.
In most federated systems, your follower list typically transfers and the old account leaves a redirect. Your posts, your direct messages, and your media usually stay on the old server unless you export and import them by hand.
Find out exactly what a migration preserves before you need it, because "you can move" and "you can move everything" are very different promises.
The operator relationship becomes visible. On a centralized platform the operator is an abstraction. On a federated one, someone specific is paying for your storage, and you can usually find out who they are, what they have said about how they run the place, and whether they are funded. That visibility is a genuine advantage, you can make an informed choice, and a genuine burden, because now you have to make one.
No single party can change the rules for everyone. Protocol-level changes require coordination across independent operators, which is slow. Slow is a feature when you have been on the receiving end of a unilateral product decision, and a defect when something needs fixing quickly.
What does not change
Network effects. The reason to be on a network is the people on it. A decentralized network with the people you want is worth joining; one without them is a well-designed empty room. No architecture has ever solved this, and the ones that claim to are describing a hope. This is the same trap that makes most substitution lists useless, discussed further in the notes on platform alternatives.
Discovery is harder, not easier. A central index is how you find things. Remove it and finding people, topics, and old conversations gets meaningfully worse, because no single party has a complete view of the network. Federated systems compensate with search that only covers part of the network, with hand-made directories, and with word of mouth. Anyone who tells you decentralisation improves discovery is not describing a system they have used to find something specific.
Someone still hosts your data. Unless you run the server yourself (which is a real option and a real ongoing commitment involving updates, backups, spam, abuse reports, and a bill), you are trusting an operator. Often an operator with fewer resources, less legal support, and no staff than the centralized company you left. Smaller is not automatically safer; it means different failure modes, most of them quieter, and the same ones that end small networks generally.
Moderation costs the same. Reviewing reports, handling abuse, and dealing with illegal content is exhausting, expensive human work. Distributing it across volunteers does not reduce the total, it changes who absorbs it, and volunteer capacity is finite in a way corporate capacity is not. The moderator hours a room actually demands are the number to estimate before choosing anything.
Bad behavior still happens. Architecture is not culture. Norms come from moderators and members, and they are as fragile here as anywhere else.
Questions to ask about a specific decentralized network
Questions Before Joining a Server
- Who operates my server
- What happens if they stop
- What moves when I migrate
- Who else can they cut me off from
- How do I find things
- What is the abuse remedy
- Where does my data live
- Can I self-host later
| Question | What a good answer looks like |
|---|---|
| Who operates my server | A named person or organization, with a stated funding model |
| What happens if they stop | A documented shutdown notice period and export process |
| What moves when I migrate | Explicitly: identity, followers, posts, and which of them do not |
| Who else can they cut me off from | Whether server-level blocks are published, and how they are decided |
| How do I find things | Whether search covers the whole network, my server, or only what I follow |
| What is the abuse remedy | The actual path when the other party is on a server with no moderator |
| Where does my data live | Whether a copy exists outside the operator, and whether you hold it |
| Can I self-host later | Whether the move is a supported operation or a manual reconstruction |
Choosing sensibly
The trade set out above is coherent, and plenty of people should take it.
If the appeal is reach, it is the wrong tool and no amount of protocol design will change that.
If the appeal is ownership, be precise about what you actually want to own. Owning your identifier, your content, and your relationship with your audience are three separate things, and different systems deliver different subsets.
The third matters most for anyone building an audience. The most reliable way to own it has always been a list of people who can reach you and whom you can reach, independent of any network at all.
Common questions
Is a federated account safer from being banned?
Safer from being removed from the whole network, yes. Not safer from being suspended by your own server's operator, who may be one volunteer with a strong opinion and no appeals process. You have swapped a large, slow, inconsistent moderator for a small, fast, personal one. Which is better depends on the operator.
Does decentralisation mean my data is private?
No, and the assumption causes real harm. Messages between servers pass through infrastructure run by strangers.
Depending on the system, server administrators on both ends may see direct messages, which is a weaker guarantee than what sealing a message does and does not cover. Treat anything sent through a federated network as readable by at least two operators unless documented otherwise.
Should I run my own server?
Only if you would enjoy administering a server, because you will be doing it indefinitely: updates, backups, storage growth, spam, and abuse reports, forever. It is the strongest form of control available and it is a standing commitment, not a setup task.
What is the honest summary?
Decentralisation is a governance change wearing a technology costume. It redistributes who decides, which is worth a lot to some people and nothing to others. It does not make communities, moderation, or discovery any easier, and it never delivers an audience.
In this guide
- Decentralized networks list: signal versus noiseDecentralized networks classified by mechanism: where the data lives, what identity is bound to, and where the power to remove sits. No figures needed.
- Three levels structure a decentralized networks directory: protocol, software, instanceDecentralized networks directory in three levels: protocol, software, and instance, with the fields each needs and the health check that keeps it honest.
- Decentralized networks facts: six behaviors of copied postsDecentralized networks facts in six behaviors: how a copied post travels and why deletion, edits, blocks and DMs work as they do on ActivityPub.
- How to assemble a decentralized networks timelineDecentralized networks timeline kept as three streams: the protocol, the software, and the instance, with the evidence each one leaves behind.
- How decentralized networks changed year by yearDecentralized networks changed year by year through five dated shifts, from shared message formats to server-blocking fights and the search problem.
- Decentralized networks have no useful rankings: six questions to ask insteadWhy ranked lists of decentralized networks and servers fail, plus six questions to eliminate options and choose a server on rules, operator, funding, and exit.
- Decentralized networks search: what catalogs should recordDecentralized networks search varies by instance. Learn how ActivityPub platforms handle discovery, with named examples and the fields a catalog should record.
- What the decentralized networks data coversDecentralized networks data: why server figures never add up to a network, what is worth observing instead, and how to store it so it stays usable.
- How to keep decentralized networks updates accurate, level by levelWhere changes surface in a decentralized networks catalog, which sources can be subscribed to, the recheck cadence for each level, and what to do with findings.







