How ActivityPub Powers the Fediverse: Federation Explained for Developers

What Is ActivityPub?

ActivityPub is a W3C Recommendation (published in 2018) that defines a decentralized social networking protocol. It provides two key things: a standardized data format for social objects (posts, likes, follows, etc.) using Activity Streams 2.0, and an HTTP-based messaging system for servers to communicate with each other.

The result is the Fediverse — a network of independent servers that can talk to each other, allowing users on Mastodon to follow users on PeerTube, interact with accounts on Pixelfed, and communicate across completely different software platforms.

The Core Concepts: Actors, Activities, and Objects

Everything in ActivityPub is expressed in terms of Actors, Activities, and Objects:

• Actor — An entity that can perform actions. Usually a Person, but also Group, Service, or Application.
• Activity — Something an Actor does: Create, Follow, Like, Announce (boost), Delete, etc.
• Object — The thing an Activity acts upon: a Note (post), Article, Image, Video, etc.

A typical post creation looks like this in ActivityPub JSON-LD:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Create",
  "actor": "https://mastodon.social/users/alice",
  "object": {
    "type": "Note",
    "content": "Hello, Fediverse!",
    "to": ["https://www.w3.org/ns/activitystreams#Public"]
  }
}

Inboxes and Outboxes: The Messaging Model

Each Actor has two key endpoints:

• Outbox — A public collection of all Activities the Actor has performed. Anyone can fetch this to see what a user has posted.
• Inbox — A private endpoint where other servers POST Activities directed at this Actor. This is how federation happens.

When Alice on mastodon.social follows Bob on fosstodon.org, Alice's server sends a Follow Activity to Bob's inbox at fosstodon.org. Bob's server processes the Activity and, if auto-accepted, sends back an Accept Activity to Alice's inbox.

From that point on, whenever Bob creates a new Note, his server looks up all followers and delivers the Create Activity to each follower's inbox — including Alice's server at mastodon.social.

HTTP Signatures: Proving Authenticity

A critical security layer in ActivityPub federation is HTTP Signatures. Since any server could claim to be sending an activity from any actor, ActivityPub implementations sign outgoing POST requests using the sender's private key. The receiving server verifies the signature against the sender's public key (fetched from their Actor document).

This prevents impersonation: a malicious server cannot forge activities from a legitimate actor without possessing that actor's private key.

What Makes the Fediverse Different from Big Platforms

Feature	Centralized Platform	ActivityPub Fediverse
Data ownership	Platform owns your data	Your server, your data
Account portability	Lock-in to the platform	Move instances (partial support)
Moderation	Central policy enforcement	Per-instance community rules
API access	Subject to Terms of Service	Open standard, self-hostable
Interoperability	Walled garden	Cross-platform by design

Getting Started with ActivityPub Development

If you want to build an ActivityPub-compatible server, here's the minimum viable implementation path:

1. Implement WebFinger discovery at /.well-known/webfinger
2. Serve Actor JSON-LD documents at user profile URLs
3. Expose /inbox and /outbox endpoints for each Actor
4. Implement HTTP Signature verification for incoming requests
5. Handle Follow, Accept, Create, and Delete activity types as a baseline

The activitypub.rocks test suite is an excellent resource for validating your implementation against the specification. The Fediverse is built on open standards — and that means you can join it.