What Does "Federated" Actually Mean?

Federation is a networking model where independent servers communicate using a shared protocol to form a unified network — without any central authority. Email is the oldest and most widespread federated system: you can send a message from a Gmail account to a Fastmail account because both servers speak SMTP.

The Fediverse applies this same principle to social media. Instead of one company's servers, thousands of independently operated instances — running Mastodon, Misskey, Pixelfed, PeerTube, or Lemmy — exchange content using the ActivityPub protocol.

The Architecture: Instances and Actors

Every Fediverse service is organized around instances (individual servers) and actors (users or automated accounts). Key architectural points:

  • Each instance is identified by its domain (e.g., mastodon.social, fosstodon.org).
  • Each actor has a globally unique identifier — a URL like https://mastodon.social/users/Mastodon.
  • Users are addressed with a @username@instance.domain handle, analogous to email addresses.
  • An instance operator controls their own moderation policies, storage, and server configuration.

The WebFinger Discovery Step

Before two instances can talk about a user, they need to discover each other. This is where WebFinger comes in — a protocol defined in RFC 7033 that lets one server look up information about a user on another server.

When you search for @alice@example.social on your instance, your server makes a request to:

https://example.social/.well-known/webfinger?resource=acct:alice@example.social

The response is a JSON Resource Descriptor (JRD) that includes a link to Alice's ActivityPub Actor document, which your server can then fetch to learn her inbox URL, public key, and profile information.

Following Across Instances: Step by Step

  1. You (on yourinstance.net) follow Alice (on example.social).
  2. Your server sends a Follow activity to Alice's inbox on example.social.
  3. Alice's server (or Alice manually) sends back an Accept activity to your inbox.
  4. Your server now knows to forward Alice's new posts to your feed.
  5. When Alice posts, her server sends a Create activity containing the Note to the inbox of every remote follower's home server.
  6. Those servers store the post locally and serve it to their users in real time.

HTTP Signatures: Trust Without a Central Authority

Since any server could theoretically forge ActivityPub requests, the Fediverse uses HTTP Signatures to authenticate inter-server communication. Each actor has a public/private key pair. When Server A sends an activity to Server B's inbox, it signs the HTTP request headers with the actor's private key. Server B verifies the signature using the actor's public key (fetched from the Actor document). This prevents impersonation without requiring a central certificate authority.

NodeInfo: Instance-Level Discovery

Beyond user-level discovery, instances advertise their capabilities via the NodeInfo standard — a JSON document at /.well-known/nodeinfo that describes the server software, version, protocols supported, and usage statistics. This allows network crawlers, client apps, and users to understand what a given instance is and what it can do before they interact with it.

Why This Architecture Matters

The federated model creates resilience: no single point of failure, no single business whose acquisition or bankruptcy can erase a social network. It also returns data sovereignty to users — you can choose an instance aligned with your values, or even self-host. The trade-off is complexity: onboarding friction, inconsistent moderation across instances, and the challenge of content discovery without a centralized algorithm.

As centralized platforms continue to face trust challenges, the federated model offers a compelling — if imperfect — alternative architecture for the social web.