How ActivityPub Powers the Fediverse: A Technical Explainer

What Is ActivityPub?

ActivityPub is a W3C-standardized protocol that enables decentralized social networking. It defines how servers communicate with each other — and how clients communicate with servers — to share activities like posts, likes, follows, and more. It is the backbone of the Fediverse: the federated universe of social platforms including Mastodon, PeerTube, Misskey, Pixelfed, and dozens of others.

Unlike centralized platforms where a single company controls all data and interactions, the Fediverse consists of thousands of independently operated servers that communicate using ActivityPub's shared language.

Core Concepts

Actors

Every entity in ActivityPub is an Actor — a user, a bot, a group, or a service. Actors are represented as JSON-LD objects with a unique URL as their identifier. For example, a user's actor document might look like:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Person",
  "id": "https://mastodon.social/users/alice",
  "inbox": "https://mastodon.social/users/alice/inbox",
  "outbox": "https://mastodon.social/users/alice/outbox",
  "followers": "https://mastodon.social/users/alice/followers",
  "following": "https://mastodon.social/users/alice/following"
}

Activities and Objects

Everything that happens in ActivityPub is expressed as an Activity wrapping an Object. Common activity types include:

• Create — Publishing a new post or note
• Follow — Following another actor
• Like — Liking a post
• Announce — Boosting/sharing content
• Delete — Removing content
• Undo — Reversing a previous activity (e.g., un-following)

Inboxes and Outboxes

Every Actor has two key endpoints: an inbox (where they receive activities from other servers) and an outbox (where their published activities are publicly accessible). When Alice on Server A follows Bob on Server B, Server A sends a Follow activity to Bob's inbox on Server B.

How Federation Actually Works: Step by Step

1. Discovery — Alice searches for bob@social.example. Her server uses WebFinger to resolve Bob's actor URL on social.example.
2. Follow request — Alice's server sends a Follow activity (signed with Alice's HTTP signature) to Bob's inbox.
3. Acceptance — Bob's server (optionally manually, or automatically) sends an Accept activity back to Alice's inbox.
4. Content delivery — When Bob creates a new post, his server sends a Create activity to all followers' inboxes, including Alice's server.
5. Display — Alice's server receives the activity, stores it, and displays it in Alice's home timeline.

HTTP Signatures: Trust in a Decentralized World

Because any server on the internet can send POST requests to any inbox, ActivityPub uses HTTP Signatures to authenticate requests. Each actor has a public/private key pair. When delivering an activity, the sending server signs the HTTP request headers. The receiving server fetches the sender's public key from their actor document and verifies the signature before accepting the activity.

This prevents impersonation — a malicious server can't forge activities pretending to be from another server's users.

The Fediverse Today

ActivityPub has enabled a thriving ecosystem of interoperable platforms:

Platform	Type	Notable Feature
Mastodon	Microblogging	Largest Fediverse network
PeerTube	Video hosting	Federated YouTube alternative
Pixelfed	Photo sharing	Federated Instagram alternative
Misskey/Calckey	Microblogging	Rich reactions and features
Lemmy	Link aggregation	Federated Reddit alternative

Why It Matters

ActivityPub represents a fundamental shift in how social platforms can be built. Instead of competing walled gardens, it enables a web of interoperable communities where users choose their provider without losing the ability to communicate with anyone on the network. The protocol is not without challenges — content moderation, spam, and discoverability remain open problems — but its adoption continues to grow as alternatives to centralized platforms attract more users.