The fediverse is a network of independently run servers that talk to each other using a shared protocol called ActivityPub, a W3C standard. Mastodon is the best-known software that speaks it, but the same protocol connects Pixelfed, PeerTube, and others. Your account lives on one server, called an instance, run by some person or group. You follow people on other instances, and the servers exchange posts on your behalf. Nobody owns the whole thing, which is the entire appeal.
That decentralization solves a specific problem: no single company can unilaterally change the rules, sell the network, or lock you in. You can move instances and take your followers with you. These are genuine wins over a centralized platform. But people often extend the win further than it goes, assuming that decentralized also means private or encrypted. It does not, and the reasons are structural.
Your Instance Admin Can See Everything
The most important fact about fediverse privacy is the simplest. The person who runs your instance has the same access to your account that a platform company would have, often with far less oversight. ActivityPub posts are stored on the server in plaintext. There is no end-to-end encryption in the protocol.
That means your instance administrator can read your direct messages, see your private posts, view your full follower and following graph, and read the IP addresses your account connects from. On a large commercial platform that access exists too, but it sits behind legal teams, audited processes, and public accountability. On a fediverse instance it may sit behind one volunteer with database access and a good or bad day.
Choosing an instance is choosing who to trust with your data. You are not removing the trusted operator from the picture; you are swapping a known company for an individual or small group whose practices, retention, and security posture you usually cannot verify. Sometimes that is a better trust. It is never no trust.
Direct Messages Are Not Private Messages
Mastodon and similar software let you restrict a post to mentioned users, which the interface often calls a direct message. This is a visibility setting, not encryption. The post is stored in plaintext on your instance, and crucially, on the instance of every person you mentioned.
So a fediverse direct message between two people on different servers exists in readable form on at least two separate machines run by at least two separate operators. If you message someone on a third instance, it lands there too. Each of those admins can read it. This is fundamentally different from a end-to-end encrypted message, where only the participants' devices hold the plaintext. For anything sensitive, the fediverse is the wrong tool, and its own developers say so.
Treat a fediverse direct message like a postcard handed through several post offices, not a sealed letter. The visibility control limits who is addressed. It does nothing about who can read it in transit and at rest.
How Federation Spreads Your Data
Federation is the mechanism that makes the network work, and it is also what scatters your content. When you post publicly, your instance delivers a copy to every server that has a follower of yours. Those servers cache it. When someone boosts your post, it propagates further. A single public post can end up stored on dozens of independent servers within seconds.
This has a consequence people discover the hard way: deletion is best-effort. When you delete a post, your instance sends a delete request out to the servers that received it. Well-behaved servers honor it. But there is no way to compel a remote server to actually erase its copy, and not all of them do. Search engines, archivers, and scraping tools also see public posts. The decentralized design that prevents lock-in is the same design that makes true deletion impossible to guarantee.
What the Fediverse Does Protect
None of this means the move is pointless. It means the benefits are different from the ones often advertised. Being precise about them helps you use the network for what it is good at.
| Property | Reality on the fediverse |
|---|---|
| No surveillance ad model | Generally true. Most instances run on donations and do not profile you to sell ads. Your attention is not the product. |
| No single corporate owner | True. No one company can sell the network, lock you in, or change all the rules at once. |
| Account portability | Real. You can migrate instances and bring your follower graph, reducing lock-in. |
| Message confidentiality | Absent. No end-to-end encryption; posts and DMs are plaintext on servers. |
| Metadata minimization | Weak. The social graph and IP logs are visible to your admin and partly inferable across the network. |
Using It Wisely
The practical posture is to treat the fediverse as a better public square, not a private channel. A few habits follow directly from how it works:
- Pick your instance like you are picking a host you trust. Read its privacy policy, its moderation record, and who runs it. You are trusting them with plaintext.
- Assume every post is permanent and public-ish. Even followers-only posts live on other servers, and deletion is not guaranteed.
- Never use fediverse DMs for anything sensitive. Move that conversation to an end-to-end encrypted channel.
- Consider a smaller, well-run instance over a giant one if the admin's transparency matters to you, but accept that smaller can also mean less security expertise.
The Honest Frame
The fediverse is a meaningful answer to platform power and surveillance advertising. It is not an answer to confidentiality, because it was not built to be one. Conflating the two leads people to put private things in a system that stores them in the open across many machines. The right mental model is layered: use the fediverse for public conversation you are comfortable having on a postcard, and use an encrypted tool for anything that needs to stay between you and one other person.
That layering is how we think about communication generally at Haven. Public, federated, and private are different jobs with different guarantees, and a tool should be clear about which one it provides. For the private job, the test is simple: can the operator read your messages? On the fediverse, by design, the answer is yes. For the conversations where the answer needs to be no, you want end-to-end encryption, where the plaintext never leaves the endpoints in the first place.