What Is ActivityPub?

ActivityPub is a W3C-standardized protocol that defines how decentralized social networks communicate with each other. Published as a recommendation in January 2018, it has since become the backbone of the Fediverse — a constellation of independently operated servers that can exchange messages, follows, likes, and other social interactions seamlessly.

If you've used Mastodon, Pixelfed, PeerTube, Lemmy, or Misskey, you've already interacted with ActivityPub, even if you didn't know it. What makes it remarkable is that an account on one server can follow, reply to, and interact with accounts on completely different software running on different servers.

The Two Halves of ActivityPub

ActivityPub is split into two distinct layers:

  • Client-to-Server (C2S): Defines how a client app (like a mobile app or browser) talks to its home server. This is used less widely in practice.
  • Server-to-Server (S2S) / Federation: Defines how servers talk to each other to deliver activities across the network. This is the part that makes the Fediverse possible.

Most real-world Fediverse implementations focus almost entirely on the S2S protocol, often using their own custom C2S APIs (Mastodon's REST API being a prominent example).

Actors, Objects, and Activities

ActivityPub is built on top of ActivityStreams 2.0, a JSON-LD vocabulary for describing social web concepts. There are three core primitives:

  1. Actors: Entities that can perform actions — typically Person, Group, Organization, or Service. Each actor has a unique HTTPS URL as their identifier.
  2. Objects: Things that actions are performed on — Note (a post), Article, Image, Video, etc.
  3. Activities: Wrappers that describe what an actor did to an object — Create, Follow, Like, Announce (boost/reblog), Delete, and more.

How Message Delivery Works

Every ActivityPub actor has an inbox and an outbox — both are HTTPS endpoints.

  • When Alice on Server A posts a note, Server A wraps it in a Create activity and sends it via HTTP POST to the inboxes of her followers on other servers.
  • Server B receives the POST, verifies the HTTP Signature to confirm it genuinely came from Server A, then stores and delivers the activity to the relevant local users.
  • Replies work in reverse: Bob's server POSTs the reply activity to Alice's inbox.

Discovery with WebFinger

Before any federation can happen, servers need to find each other's actors. This is where WebFinger comes in. When you enter @alice@mastodon.social into a Fediverse app, it queries:

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

The response is a JRD (JSON Resource Descriptor) that links to Alice's ActivityPub actor profile URL. From there, the full actor JSON — including inbox, outbox, and public key — can be fetched.

Security: HTTP Signatures

Because any server can POST to any other server's inbox, ActivityPub relies on HTTP Signatures (using an actor's RSA public/private key pair) to authenticate message origin. Each actor's public key is embedded in their profile JSON. Receiving servers validate the signature before processing any activity.

Why It Matters

ActivityPub shifts power away from centralized platforms. Users choose a server that aligns with their values, yet still participate in a global social graph. Server operators can moderate their own communities without isolating their users from the wider network. It's an architecture that makes the social web more resilient, interoperable, and pluralistic.

As more platforms — including large mainstream ones — explore federation, understanding ActivityPub is increasingly essential for any developer working on social software.