What Is ActivityPub?

ActivityPub is a W3C Recommendation (published January 2018) that defines both a server-to-server federation protocol and a client-to-server API for decentralized social networking. It's the backbone of the "Fediverse" — the constellation of interconnected, independently operated social platforms including Mastodon, Pixelfed, PeerTube, Lemmy, and many more.

The key insight behind ActivityPub is that social interactions — posting, following, liking, sharing — can be standardized as messages exchanged between servers. Two servers that speak ActivityPub can interoperate even if they run completely different software.

Core Concepts

Actors

Every entity in ActivityPub is an Actor — a user, a bot, a group, or a service. Each Actor has a unique URL (their identifier) and publishes a JSON-LD document at that URL describing their properties and important endpoints:

  • inbox — Where other servers POST activities meant for this actor
  • outbox — A public collection of activities this actor has performed
  • followers / following — Collections listing social relationships

Activities and Objects

Everything that happens in ActivityPub is modeled as an Activity wrapping an Object. Activities use a standardized vocabulary from the ActivityStreams 2.0 spec:

  • Create — Publishing a new post, image, or video
  • Follow — Requesting to follow another actor
  • Like — Expressing appreciation for an object
  • Announce — Sharing/boosting another actor's content
  • Delete — Removing content or an actor
  • Undo — Reversing a previous activity (e.g., unfollowing)

The Federation Flow

Here's how a simple follow-and-post interaction works across two servers:

  1. User A on social.example follows User B on another.instance.
  2. Server A sends a Follow activity as a POST to User B's inbox URL.
  3. Server B accepts and sends back an Accept activity to User A's inbox.
  4. When User B creates a new post, Server B sends a Create activity to the inboxes of all followers — including User A's inbox on Server A.
  5. User A sees User B's post in their timeline, even though they're on different servers.

Security in ActivityPub: HTTP Signatures

Because any server can POST to any inbox, ActivityPub uses HTTP Signatures to verify that an activity genuinely came from the claimed sender. Before delivering an activity, the originating server signs the HTTP request using its private key. The receiving server fetches the sender's Actor document to get the public key and verifies the signature.

This prevents impersonation but doesn't prevent spam or harassment — which is why instance-level blocklists and defederation remain important moderation tools in the Fediverse.

WebFinger: The Discovery Layer

Before two servers can interact, they need to resolve human-readable addresses like @alice@social.example into Actor URLs. This is done via WebFinger (/.well-known/webfinger), which maps an account identifier to its ActivityPub Actor document URL.

ActivityPub vs. Other Federation Protocols

Protocol Primary Use Status
ActivityPub Decentralized social networking W3C Recommendation
OStatus Earlier Fediverse standard (Statusnet era) Largely superseded
Diaspora Protocol Diaspora network federation Active (niche)
AT Protocol Bluesky federation Evolving

Why Developers Should Care

ActivityPub represents a mature, W3C-standardized approach to building interoperable social features without platform lock-in. If you're building community tools, publishing platforms, or social applications and want users to connect across instances, implementing ActivityPub means your users can interact with millions of existing Fediverse accounts from day one.