A timeline without a landlord.

Why federation matters

Centralized social networks make one promise quietly: your identity is rented. Your handle, your followers, your post history, your DMs — all of it lives in someone else’s database and is administered by someone else’s policy team. A bad day at Twitter / X / Meta is a bad day for everyone on it. The cost of that arrangement isn’t the monthly fee; it’s the absence of an exit.

Federation, the way ActivityPub does it, decouples three things that the centralized networks fused: identity, hosting, and reach. Identity is a domain you own. Hosting is a server somewhere on the open web. Reach is the network of other servers that subscribe to yours via a published protocol. If any one of those three breaks, the other two survive. That’s the whole pitch.

Federation is the only social architecture where you can move out of the building without leaving the city. — Operating principle, social domain

Anatomy of an instance

A federated social instance looks like a small constellation of roles. None of them are exotic; the trick is the choreography.

• Web — the API and user-facing HTML. The thing browsers and mobile apps talk to.
• Streaming — long-lived connections that push timeline updates in real time.
• Workers — background delivery. Federation is mostly async; outbound fan-out runs as jobs.
• Database — the canonical store for accounts, follows, notifications, and media metadata.
• Cache — ephemeral state, queues, and timeline acceleration.
• Object storage — media cache and locally authored attachments.

PUBLIC VIEW
web surface     live      public protocol
streaming       live      route hidden
workers         live      queue names hidden
database        private   storage hidden

At idle the whole thing runs at about 1.8 GiB resident and roughly 12% of one core. The active surface area is small enough that I’ve memorized which container handles which symptom, which is the real KPI of a sustainable self-hosted service.

How federation actually works

The hand-wave version: ActivityPub is HTTP + signed JSON-LD. When I post, my server PUSHes a signed payload to every server that has at least one follower of mine. When a remote user replies, their server PUSHes a signed reply to mine. There’s no central index; there’s just a graph of mutual subscriptions and a lot of HTTP.

The non-hand-wave version exposes three sharp edges:

1. Public-key identity. Every actor (account) publishes a public key at a stable URL. Every signed delivery is verified against that key. If a server gets compromised, you rotate its actor keys and reannounce; remote servers re-fetch and continue. The protocol assumes the network is hostile.

2. Fan-out cost. When a popular remote user with 50,000 followers posts, their server has to push that one payload to potentially thousands of receiving servers. If either side’s worker queue is slow, delivery arrives late. Federation latency is a queue-throughput problem, almost always.

3. Blocking is a one-server decision. When I block a remote server — for harassment, spam, content I refuse to host — I’m only making the policy for my instance. Other instances that follow that server still see their posts. The fediverse is not a monoculture and never will be; you’re always living inside the union of your federation graph and your domain policy.

Moderation at a population of one

A single-user instance flips the moderation problem. There’s no community to manage. The only policy decisions are about what I see and what my server will relay. I subscribe to a couple of community-maintained block lists (the “no-Nazi” list, the standard scam-and-spam list), I add my own additions when something specific shows up, and I let the rest of the fediverse argue about the rest.

The thing this clarifies, in a way I didn’t expect: moderation at scale isn’t about content, it’s about cost-sharing. A big instance moderates because the alternative is having one user’s harassment problem become every user’s harassment problem. A single-user instance only has one user, so the cost externality vanishes. You moderate yourself by curating who you follow. The graph does the work.

Storage, media, and the disk cost

The big surprise of running a federated social instance is media. Every image, video, and audio file from every remote post you can see gets cached on your disk by default. That’s how the timeline can render quickly — your server doesn’t have to re-fetch from a remote host for every scroll.

Without cleanup, a casual instance can grow quickly from media cache. The fix is a scheduled cleanup policy that prunes remote media after it stops being useful while preserving locally authored posts.

What downtime feels like

When my instance is down, the fediverse doesn’t notice much. Other servers keep trying to deliver posts for a while, and local outbound work queues until the instance comes back. Nothing dies. Nothing data-corrupts. The graceful-degradation properties of federation are the part that’s hardest to feel until you’ve been through three or four mini-outages.

Compare to centralized: when Twitter is down, your entire identity is unreachable for the duration. When your federated instance is down, the rest of the network keeps talking and your followers see the gap as a quiet patch in the timeline.

The point isn’t uptime. The point is that downtime stays local. — Notes after the 2025 ice-storm outage

Takeaways

Running my own social server stopped being a political statement around year two. It became a default. The character of my feed is different — nobody’s optimizing for engagement, nobody’s injecting recommended posts, no thread is ever fifteen minutes from going viral. I post less and read more. The signal-to-noise ratio is higher because the network isn’t shaped like a casino.

The infrastructure cost is real: about 2 GiB of RAM and an attentive operator. The dividend is that nobody can take this account away from me — not a billionaire, not a policy team, not an outage at someone else’s vendor. Identity, hosted at home, federated by protocol.