On 23 January 2018, the World Wide Web Consortium published ActivityPub as a W3C Recommendation.
That sentence is doing more work than it looks. A Recommendation is the end of the W3C process — it is what HTML and CSS are. It means a working group spent years specifying how independent social servers talk to each other, and then published the result as a standard anyone may implement without asking permission.
So when the previous file argued that the answer to coordination is an agreed interface rather than a bigger institution, this is not a thought experiment. Somebody wrote the interface down and it has a specification number.
That last line is the Unix pipe with a W3C number on it. Two codebases with nothing in common, interoperating, because they agreed how to talk rather than agreeing what to be. Standardise the interface, not the participants — shipped, dated, and in production.
Before arguing that federation can work at scale, it is worth noticing that you have been using a federated network every working day of your life.
Email is the case that settles the feasibility question. Nobody owns it. Your provider and mine share no code, no company and no terms of service, and a message still arrives. Billions of them. It has run for four decades on exactly the architecture File №09 describes: autonomous servers, one agreed protocol, no centre.
And it is also the warning, because look at what happened to it.
The standard never changed. Anyone may still run a mail server, and the specification still says every server is equal. But once a small number of providers hold most of the mailboxes, their spam heuristics become the real protocol, and a new independent server has to earn permission to be heard from operators it never agreed to be governed by.
That is centralisation by reputation rather than by ownership, and it is the most instructive failure in this whole file: an open standard is necessary and it is not sufficient. You can win the specification and still lose the network.
File №09 listed protocol capture as a failure mode — standards quietly coming to serve the few. Here is that failure mode with a year, a company and a stated reason.
XMPP is an open standard for real-time messaging, and in the late 2000s Google built Google Talk on it. That mattered enormously: it meant a user on a small independent server could message a Google user directly, because Google’s servers federated with everybody else’s. For a while, the largest chat network on earth spoke an open protocol.
On 15 May 2013, at its own developer conference, Google announced the move to Hangouts. The part that mattered was not the rebrand. It was that Hangouts dropped server-to-server federation — the exact half of the standard that let other servers reach it. The Electronic Frontier Foundation’s write-up that month was titled, simply, Google Abandons Open Standards for Instant Messaging.
Every large network can say that at some point, because federation is always a minority of traffic before it is a majority. The argument is available whenever it is convenient, and it is unfalsifiable from inside the company making it.
The consequence was immediate and permanent. Independent XMPP servers could no longer reach the largest population of users on the network, so being on an independent server stopped being useful, so people left. The protocol was never withdrawn. It simply stopped mattering once the biggest participant declined to speak it outward.
That is worth naming precisely, because it is the risk that applies to every network in this file: a federated protocol does not die when it is banned. It dies when the largest implementer keeps the client half and drops the server half.
Tap any of them. The pattern that separates the living from the dead is not technical quality — it is whether the biggest participant still has a reason to federate outward.
Any guide that tells you to join the fediverse without telling you how big it is has decided to sell you something. So, plainly.
Monthly active users in November 2022, in the weeks after the Twitter acquisition. It has not come close since.
Monthly active users through 2025 and 2026 — below 690,000 at the October 2025 low, and roughly 750,000 to a million in 2026.
Across the whole fediverse — Mastodon, Pixelfed, PeerTube and the rest — there are over 11 million registered accounts on more than 10,000 independent servers, and something like one to two million people actually using them in a given month. The gap between those two numbers is the real story: most people who signed up did not stay.
For comparison, that is a rounding error against any centralised platform. The fediverse did not win. It is not winning.
Here is why it is still the subject of a file. It exists, it is standardised, it is governed by nobody, and it is running right now — which is more than can be said for most alternatives to anything. The question is not whether it has already succeeded. It is whether the thing you want is a large audience or an arrangement you are not a tenant in, because at present you are being offered a genuine choice between those two and not a free lunch.
And the failure mode it is currently exhibiting is the eighth one from the previous file, the least dramatic and most common: apathy. People disengage. The design answer there was to make participation rewarding and short, and to respect the hour. Most of the eight practices below are, read honestly, attempts to do exactly that.
The first two steps are the ones people get wrong in the same way: they treat joining a federated network like signing up for a product, and then wonder why it feels empty.
Join a community
- Pick a server the way you would pick a neighbourhood, not a brand — who runs it, what it is about, what its rules are
- Introduce yourself; on a federated network nothing is recommending you to anyone, so the first move is yours
- Say what you are interested in, because that is the entire discovery mechanism
Use open tools
- Try the federated platforms — Mastodon for posting, Matrix for chat, PeerTube for video
- Keep your data: the test of whether you own an account is whether you can leave with it
- Support open source, which in practice means the unglamorous part — paying the person running your server
That last point deserves more than a bullet. On a centralised platform the hosting is paid for by selling your attention. On a federated one somebody is paying a hosting bill, usually personally, usually monthly. An instance with no funding model is an instance with an expiry date, and choosing one is a question you should ask before you have five years of posts on it.
Create something
- Write, teach, or make art — a network with no creation on it is a waiting room
- Start a community project, however small
- Share resources freely, and licence them so somebody else can build on them
Support others
- Help newcomers; the first week is when almost everybody who leaves, leaves
- Answer questions that have obvious answers, patiently, again
- Be welcoming on purpose rather than by default
There is a structural reason kindness is load-bearing here rather than decorative. A centralised platform retains you with recommendation engines, notifications and a feed engineered against your attention. A federated one has none of that machinery and does not want it. The retention mechanism is other people being glad you turned up. That is not a slogan on this network; it is the only thing in the position where the algorithm usually sits.
This is the step that decides whether any of the rest survives, and the guides usually give it one line. It deserves several, because federated moderation is genuinely harder than centralised moderation — not easier.
Moderate fairly
- Set clear, simple rules, published before you need them
- Listen to different perspectives, and distinguish that from hosting abuse
- Keep communities safe and open, which is a tension and not a slogan
Here is the honest shape of the difficulty. On a centralised platform, moderation is one company’s policy applied badly at enormous scale. On a federated one, every instance sets its own rules — which is the good part — and then has to decide what to do about every other instance, which is the hard part.
The tool for that is defederation: an instance deciding it will no longer exchange messages with another. It is the network’s immune system and it is also its most contested act, because it is simultaneously a community protecting itself and a small number of admins deciding what the rest of their users may see. Both descriptions are accurate at the same time.
What makes it legitimate rather than arbitrary is the same list from the last file: the rule was published in advance, the decision is visible, the person who made it is named, and it can be reversed. Make permissions visible. Make revocation ordinary. A defederation nobody can find a reason for is protocol capture at small scale.
And the thing worth being clear-eyed about: moderation is unpaid labour on this network, almost always, done by the same person paying the hosting bill. Burnout is the documented failure mode of mutual aid, and instance administration is mutual aid.
Bridge communities
- Share across platforms rather than demanding people move to yours
- Collaborate on shared goals — the handshake from File №09, run for real
- Welcome different viewpoints, which is not the same as welcoming everything
Stay informed
- Learn what digital rights you actually have where you live
- Understand how the fediverse works — at minimum, what your instance can see, what it federates, and who administers it
- Follow the updates from the people running the infrastructure you depend on
Step seven is the defence against step three of this file. The XMPP capture worked partly because most users had no idea federation was the thing being removed — they experienced a rebrand and a slightly different app. A network whose users cannot tell when federation is switched off has no defence against it being switched off.
Keep going
- Stay engaged, at a rate you can sustain for years rather than weeks
- Adapt and improve — the protocol is a standard, but the practices around it are not finished
- Encourage others, and mean the specific ones you know
Set the three files beside each other and the shape is clear enough. File №08 is an associational answer that was padlocked by a government. This one is an associational answer that was closed by a company — no statute required, just a product decision announced at a developer conference. The instrument changed. The result did not.
What is different this time is that the standard survived the capture. XMPP is still a standard. ActivityPub is a Recommendation that Google cannot withdraw, because the W3C published it and no single participant owns it. That is the entire practical value of writing the interface down: it means losing the network does not mean losing the ability to rebuild it.
A kinder internet isn’t a dream. It’s a choice — made by people, every single day.
People, stronger together. Communities, real connections. Protocols, open and adaptable. A freer tomorrow, within reach — which is a considerably smaller claim than already here, and the right one.
- The Federation, File №09 — Federation Is a Protocol. The architecture this file is a field report from.
- The Federation, File №08 — The Monster Was Real. The same associational answer, closed by statute instead of by product decision.
- The Federation — The Crime of Meeting. What happens when association itself is the charge.
Ten ready-to-post lines from the page above. Every one carries the link back here.
