The Fediverse Feels Like the Old Web, On Purpose

The first time I set up a Mastodon account, it felt oddly like configuring email in the 1990s. I had to pick a server, decide whether I trusted its administrator, understand that my address was tied to that specific server’s domain, and accept that if the server disappeared, my account went with it unless I’d planned an export in advance. None of that is an accident or a rough edge waiting to be smoothed away. It’s the entire point. The fediverse deliberately rebuilt the part of the internet that centralised platforms spent twenty years designing away — the part where no single company controls who can talk to whom — and it feels like the old web because it’s solving the same problem the old web solved, using the same basic shape.

Email is the fediverse’s closest living ancestor, and it’s worth being precise about why. You can run your own mail server, or use Gmail, or use a small independent provider, and still send mail to anyone on any other provider, because SMTP is an open protocol nobody owns. Nobody had to ask Google’s permission to run a competing mail server in 2004, and nobody has to ask a social media company’s permission to run a competing microblogging server today, provided that server speaks the same open protocol everyone else agreed to. That protocol, for the fediverse, is called ActivityPub, and understanding what it actually does is the key to understanding why this whole ecosystem behaves the way it does. It’s the same open-protocol logic that makes open source itself such an unusual act of collective generosity: nobody owns the standard, so nobody can unilaterally revoke anyone else’s participation in it.

What ActivityPub actually is

ActivityPub is a W3C-standardised protocol for servers to exchange social activities — posts, likes, follows, boosts — in a common format, so that a Mastodon server, a Pixelfed server (photos), a PeerTube server (video) and a Lemmy server (link aggregation, Reddit-shaped) can all talk to each other without any of them needing special-case code for the others. A user on one server can follow, reply to, and interact with a user on a completely different server running completely different software, because both servers speak the same protocol underneath their different interfaces.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

[email protected]        [email protected]
        |                             |
        |  1. Alice follows Bob       |
        |----------------------------->|
        |  2. Bob's server delivers   |
        |     his new posts to Alice's|
        |     server as ActivityPub   |
        |     "Create" activities     |
        |<-----------------------------|
        |  3. Alice's server renders  |
        |     Bob's photo posts in    |
        |     her timeline, even      |
        |     though her app has      |
        |     never talked to         |
        |     Pixelfed's software     |

This is the mechanism that lets someone on a small, independently-run server follow someone on a completely different app with a different feature set. It’s also the mechanism that means no single company can unilaterally change the rules for everyone, because there is no “everyone” to change rules for — there are thousands of independently-administered servers, each running its own moderation policy, each capable of choosing to federate or not federate with any other server based on its own judgement.

Why this shape produces the experience it does

The old-web feeling comes directly from this architecture, not from any deliberate aesthetic choice. Centralised platforms optimise for one experience across a billion accounts because one company’s incentives — engagement, ad revenue, growth — apply uniformly to every user. A fediverse server, by contrast, is usually run by a much smaller operator (sometimes one person) for a much smaller, more self-selected community, and the experience reflects that: smaller timelines, moderation that actually responds to reports because the admin knows the community, and rules that vary meaningfully from server to server because there’s no single set of Terms of Service being applied planet-wide.

The trade-off runs in both directions. A small independently-run server can shut down, and unlike a centralised platform there’s no guarantee of a smooth migration path unless the admin planned for it and users exported their data in advance — a real failure mode, not a hypothetical one, and one that’s already happened to communities that assumed their server was permanent. On the other hand, no single company can unilaterally decide to change the algorithm, inject advertising into your timeline, or sell access to your data to a partner network, because there’s no central entity with that authority over the whole system — the authority is distributed across every server’s own admin, for better and for worse.

What “instances” actually mean in practice

The word “instance” trips people up more than any other fediverse concept, because there’s no equivalent concept on a centralised platform to map it onto. When you join a corporate social network, you’re joining the one and only version of that network. When you join the fediverse, you’re joining one specific server among thousands, and that server is a real, distinct piece of software with its own database, its own uptime, its own rules, run by a specific admin or small team you can usually name. Your account’s full identity includes that server — @[email protected], not just @alice — for the same reason your email address includes a domain: because “alice” alone is meaningless without knowing which mail server it lives on.

This matters practically in a way that trips up new users constantly. Search on the fediverse is scoped to what your own server and the servers it federates with have actually seen, not a global index of every post ever made — there’s no central index to search, because there’s no central server holding all the data. A post that hasn’t reached your server yet, because nobody your server follows has interacted with it, effectively doesn’t exist from your vantage point until it does. This isn’t a bug the software forgot to fix; it’s the direct, unavoidable consequence of there being no single database behind the whole network. Relay servers exist specifically to widen what any given instance sees, by aggregating public posts from many servers and redistributing them, but even relays only cover a fraction of the whole network at any given time.

Choosing an instance is also choosing a moderation policy, a content-visibility default, and a community, all at once, which is a genuinely different decision than picking a username on a centralised platform ever was. A server dedicated to a specific hobby, region or profession tends to have tighter, more relevant moderation than a large general-purpose instance, in the same way a well-run mailing list beats a firehose. Picking the wrong instance for what you actually want out of the network is the single most common reason people bounce off the fediverse after a week, usually because they joined the equivalent of a specialist forum while expecting the reach of a mass-market platform.

Portability is the safety net, and most people skip it

Because your identity lives on a specific server, that server disappearing is a real risk, and the fediverse’s answer to that risk is data portability rather than platform permanence. Most servers let you export your follower list, your posts, and your account settings, and several support “account migration,” which redirects your old followers to a new address on a different server without them having to manually re-follow you. This is the feature that makes the decentralised model survivable rather than merely idealistic — but it only works if you’ve configured it, or at least exported your data, before the server you’re on actually goes down, and in practice most users never touch these settings until it’s too late to matter.

I treat this the same way I treat backups for anything else I run: the export only has value if it happened before the failure, and a policy of “I’ll deal with it when the server announces it’s shutting down” assumes you’ll get meaningful advance notice, which smaller volunteer-run instances don’t always give. Exporting your follower list every few months costs almost nothing and removes the single biggest practical argument against trusting a small, independently-run server with your identity.

Running your own instance

Anyone can stand up a server, and doing so is where the “old web” feeling gets most literal — you’re back to being responsible for your own small piece of infrastructure, the way running a personal website or a mail server used to mean.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# docker-compose.yml — minimal Mastodon-style single-user instance
services:
  web:
    image: tootsuite/mastodon:latest
    environment:
      LOCAL_DOMAIN: social.example.com
      SMTP_SERVER: mail.example.com
      SMTP_LOGIN: [email protected]
    depends_on:
      - db
      - redis
  db:
    image: postgres:15-alpine
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
  redis:
    image: redis:7-alpine
    volumes:
      - ./data/redis:/data

Running a single-user or small-community instance is a genuinely different maintenance burden to using someone else’s server, and it’s worth being honest about what it involves before committing: database backups, federation debugging when a remote server can’t be reached, moderation tooling if you ever grow past a handful of trusted users, and a domain you’re responsible for keeping alive if you want your identity to persist. It’s the same trade-off as self-hosting email — total control over your own presence, in exchange for being the person who gets paged when it breaks.

The moderation trade-off nobody mentions upfront

Centralised platforms get criticised constantly for inconsistent moderation, and fairly so, but they at least apply one policy everywhere, which means a user knows roughly what to expect regardless of which corner of the platform they’re in. The fediverse trades that consistency for something closer to genuine local judgement: a small instance’s admin can respond to a report within hours because they actually know the handful of accounts involved, but that same smallness means there’s no appeals process beyond emailing that one person, and no guarantee the next admin who takes over the server will hold the same standards. I’ve seen well-run instances with excellent moderation records built entirely on one admin’s personal diligence, with no institutional backup if that person steps away.

Defederation — one server deciding to stop accepting traffic from another — is the fediverse’s blunt instrument for handling bad actors at scale, and it works better than it sounds. When an instance becomes a haven for harassment or spam, other admins can simply stop federating with it, which cuts its users off from the wider network without requiring any central authority to intervene. This is the same mechanism email providers use against spam-friendly mail servers, and it has the same limitation: it only works once enough other admins notice and act, which can take time the people being harassed in the meantime don’t have.

Troubleshooting federation problems

Federation issues are the most common category of fediverse-specific problem, and they behave differently to a normal web app outage because the symptom shows up on a remote administrator’s server, entirely outside your own control.

Posts aren’t reaching followers on another server. Check that server-to-server HTTP signatures are validating correctly — ActivityPub relies on signed requests between servers, and a clock skew or a misconfigured reverse proxy stripping headers can silently break delivery in one direction while everything looks fine locally.

A remote server appears to have blocked yours without explanation. Some admins maintain defederation lists for servers with a history of abuse or lax moderation, and a newly-created instance can occasionally be caught by an overly broad blocklist rule. Reaching out to the remote admin directly is usually more productive than assuming malice.

Follows from a remote server silently stop delivering after working initially. This is often a queue backlog on the sending server rather than a problem on the receiving end — check the remote server’s status page or ask in its community channels before assuming your own instance is at fault.

Is it worth using

If what you want is a single feed with everyone you know already on it, the fediverse will frustrate you, because that’s explicitly not what it optimises for — the whole design assumes fragmentation into smaller communities is a feature, not a bug to be fixed. If what you want is a social space that no single company can unilaterally reshape around advertising incentives, and you’re willing to trade a slightly rougher, more old-web experience for that, it delivers on exactly what it promises. I run my own small instance for the same reason I run my own self-hosted messaging rather than trusting a platform I don’t control: not because the corporate alternative is broken today, but because the fediverse doesn’t require me to trust that it won’t be tomorrow.