ActivityPub is an open protocol, published as a W3C Recommendation in January 2018, that lets independent social servers exchange posts, follows and likes. It is the defining standard of the Fediverse, so different apps can talk to each other.
It is one of the building blocks covered in the wider community platform guide to tools and protocols.
What ActivityPub does
ActivityPub provides a client-to-server (C2S) API for creating and modifying content, as well as a federated server-to-server (S2S) protocol for delivering notifications and content to other servers, according to Wikipedia’s overview of the protocol. The same source describes it as the defining standard of the Fediverse, a decentralised network made up of independently managed instances of software.
In practice this means no single company owns the network. A person on one server can follow, reply to or boost a person on another, much as email works across providers. Each server decides its own rules, while the protocol handles delivery.
How the protocol works
ActivityPub uses the ActivityStreams 2.0 format for building its content, which itself uses JSON-LD. Posts, profiles and actions are all described as structured JSON objects that any compliant server can read.
Actors, inboxes and outboxes
Every actor type contains an inbox and outbox stream, which sends and receives activities for a user. An actor can be a person, but also a group, an organisation or a service. Each actor is addressed by a URL, which is how other servers find it.
Publishing an activity
To publish data, such as liking an article, a user creates an activity that declares the like and publishes it to their outbox. The server then delivers it by a POST request to the inboxes listed in the activity’s to, bto, cc and bcc fields. Those addressing fields decide who sees it: followers, a named person, or the public.
From OStatus to a W3C standard
The standard was first published by the World Wide Web Consortium (W3C) as a W3C Recommendation in January 2018 by the Social Web Working Group, a group chartered to build the protocols and vocabularies needed for social functionality. Further development then moved to the Social Web Community Group, as the same Wikipedia entry records.
The older approach, OStatus, combined several technologies, including Atom, Salmon, WebSub and WebFinger. That stack was a product of the infrastructure used in GNU social and made the protocol difficult to implement in new software. ActivityPub replaced that patchwork with one JSON-based design, which is a large part of why new projects adopted it.
Software that speaks ActivityPub
The list of compatible software spans very different tools. Wikipedia’s table of implementations includes Mastodon for microblogging, Pixelfed for images, PeerTube for video, Lemmy for link aggregation and forums, and Mobilizon for events and groups. Because they share a protocol, a Mastodon user can follow a PeerTube channel without a separate account.
This variety makes ActivityPub useful beyond social media. Communities can run forums, calendars or media libraries that interoperate, a theme explored in the guide to the open source community platform landscape.
A worked example: following someone on another server
Following a person on a different server shows the design clearly. The follower’s server creates a Follow activity addressed to the target actor and delivers it to that actor’s inbox. The target’s server records the request, and either accepts it automatically or waits for the person to approve it. Once accepted, the target’s server knows which inboxes to deliver future posts to.
From then on, every new post follows the publishing pattern described above. The author’s client hands the post to the home server, the server places it in the outbox, and a POST request carries it to the inbox of each follower’s server. Those servers show it in the followers’ timelines. Replies work the same way in reverse, so a conversation can span several servers while each one stores only the copies it has received.
Likes, boosts, edits and deletions are all activities too. Deleting a post means sending a Delete activity to the servers that received it. Each receiving server decides whether to honour the request, which is one reason deletion across a federated network is a polite request rather than a guarantee.
Why federation changes community design
For community builders, the main attraction is control. A group can run its own server, choose its own moderation rules and still reach people elsewhere. A hobby forum, a local events calendar or a neighbourhood video channel does not need to persuade members to join a large commercial platform. The members keep their accounts on a server the community trusts, while the protocol connects them outward.
The model also changes who carries the costs. On a centralised service, one company pays for storage, delivery and moderation. On a federated network, those tasks spread across many operators, each of whom decides how much to host and whom to connect with. Small servers can follow popular accounts without holding the entire network’s content, because they receive only what their users subscribe to.
There are trade-offs for organisers. Running a server means handling updates, backups and abuse reports. A community that wants the benefits of federation without that work can join an existing instance, but then relies on that operator’s policies. Weighing those options is similar to the choices made in any self-hosted community project.
Limits and comparisons
ActivityPub specifies how servers exchange activities, but not how they moderate. Each instance sets its own policies and can block others, so the experience varies from server to server. Identity is also tied to the home server, which makes moving accounts harder than the protocol’s openness suggests.
It also solves a different problem from real-time messaging. Group chat is handled by separate open standards, such as the one behind matrix chat, which replicates conversation history across servers instead of delivering posts to followers.
Interoperability itself is also uneven. Because the specification leaves room for extensions, two programs that both claim support can differ in what they display. A video platform may attach fields that a microblogging app ignores, and some features, such as private groups or long-form formatting, may not carry across. Developers usually test against several popular implementations to find these gaps, and users sometimes notice them as missing replies or truncated posts.
Understanding these limits helps set realistic expectations. ActivityPub makes cross-server publishing possible, but it does not make every server identical, and it does not remove the need for human moderators and clear community rules.
Getting started with the Fediverse
New users do not need to understand the protocol to use it. The usual path is to pick a server that matches an interest, such as a general microblogging instance, a photo community or a video host, and create an account there. From that account, search for people on other servers by their full handle and follow them. The two software projects do the protocol work in the background.
Developers have a lower barrier than the OStatus era offered. The specification is built on JSON, so a small service can publish an actor document, accept activities at an inbox and send activities from an outbox. Many projects begin by making a blog or site readable as an actor, then add replies and likes later. The W3C text and the Social Web Community Group remain the reference points for questions about edge cases.
Frequently asked questions
Is ActivityPub the same as the Fediverse?
No. The Fediverse is the network of servers and apps. ActivityPub is the protocol that most of them use to communicate.
Who created ActivityPub?
It was published by the W3C Social Web Working Group as a W3C Recommendation in January 2018.
What data format does ActivityPub use?
It uses ActivityStreams 2.0, which in turn uses JSON-LD.
Do users need an account on every server?
No. One account on any compatible server can follow and interact with actors on other servers, because servers deliver activities to each other’s inboxes.
