What Is ActivityPub? The Protocol That Lets Mastodon, PeerTube, and Lemmy Talk to Each Other

Open a Mastodon client on C.IM, search for a channel on P.LU, follow it, and wait for the next upload. The video can show up in your Mastodon timeline even though it was published on PeerTube.

Pause there. A Twitter account cannot follow a YouTube channel in the same native way. You can paste links between the two, of course. You can embed, cross-post, and automate a few things if both sides allow it. But the follow relationship itself belongs to each company’s platform.

The Fediverse takes a different route. Mastodon, PeerTube, Lemmy, Pixelfed, WriteFreely, and a long list of smaller projects speak ActivityPub. Think of it like SMTP for social software. Gmail, Outlook, and a self-hosted mail server do not need the same owner or the same interface to exchange email. They need a shared delivery format.

ActivityPub gives social apps that shared format.

The standard, in plain terms

ActivityPub became a W3C Recommendation on January 23, 2018. W3C is the standards body behind many web specifications, so the recommendation gave implementers something stable to target.

The ActivityPub specification covers two jobs. One is client-to-server: an app talks to your home server to create, update, or delete content. The other is server-to-server: your server delivers activities to other servers and receives activities from them.

Most people notice the server-to-server part first. You follow someone on another domain. Your server stores that relationship. When the remote account posts, your server receives the activity and puts it where your client can show it.

ActivityPub was already running in the wild before the W3C date. W3C’s announcement said it was deployed across thousands of Mastodon instances with more than one million registered users. Mastodon had also moved early: the v1.6.0 release notes, published on September 10, 2017, called ActivityPub Mastodon’s primary protocol while keeping OStatus compatibility during the transition.

Why ActivityPub replaced the older stack

The older federated social web had OStatus. It worked, and it deserves credit for that. It also asked developers to assemble several pieces at once: Atom, Activity Streams, WebSub, Salmon, and WebFinger. The OStatus history reads like a pile of reasonable standards that became awkward when every new server had to implement the whole bundle.

OStatus also came from a microblogging world. A short status update fit naturally. A video platform or forum could use the same network, but the fit was less comfortable.

ActivityPub did not remove all complexity. Anyone who has debugged federation queues knows better. It did give developers a cleaner set of concepts: actors, inboxes, outboxes, and activities such as Follow, Create, Like, Announce, and Delete.

Dry, yes. Good protocols usually are.

Actors, inboxes, outboxes, and WebFinger

An Actor is the account, channel, group, or service that does something. In Mastodon it is usually a person account. In PeerTube it might be a channel. The ActivityStreams vocabulary includes actor types such as Person, Group, Organization, and Service, and ActivityPub actors expose endpoints such as an inbox and outbox.

The mailbox metaphor is useful enough here. The outbox is where an actor publishes activities. The inbox is where another actor receives them. The ActivityPub overview describes that shape directly: clients can post to an actor’s outbox, and federated servers can post to a remote actor’s inbox.

The verbs say what happened. Follow asks for updates from another actor. Create wraps new content. Like records a favorite or approval. Announce is the activity behind a boost or share. Delete tells other servers that an object should go away. The server-to-server section is where those delivery rules become federation behavior rather than just JSON vocabulary.

Then there is lookup. People type handles such as @[email protected]; servers need actor URLs and inbox URLs. Mastodon’s WebFinger documentation describes the lookup from user@domain to actor profile URI, and the underlying WebFinger protocol is RFC 7033.

WebFinger is not DNS. The comparison is still useful: DNS helps software find a host; WebFinger helps Fediverse software find the actor behind a handle.

Why different apps can understand each other

Mastodon, PeerTube, and Lemmy do not become the same app because they use ActivityPub. They only agree on enough grammar to pass messages.

Mastodon usually publishes a short post as a Note. PeerTube can publish video objects. Lemmy deals in communities, posts, links, and comments. The ActivityStreams vocabulary has room for object types such as Note, Video, Page, Article, Image, and Audio, so a server can describe both the object and the activity around it.

The receiving software still has work to do. Mastodon may show a PeerTube upload as a status with a video preview. PeerTube may show a Mastodon reply as a comment. Lemmy may display a remote account inside a thread. Some of this is smooth; some of it is awkward. Federation is real, but presentation is still software-specific.

Email is the closest everyday analogy. Gmail and a self-hosted mail server do not share a UI, storage engine, spam filter, or business model. They can still exchange messages because they agree on delivery.

ActivityPub applies that idea to follows, posts, replies, boosts, and related social actions.

Following P.LU from C.IM

In practice, the P.LU and C.IM flow is not mysterious.

Log into C.IM with a Mastodon client. Copy the address or profile URL of a PeerTube channel on P.LU. Paste it into Mastodon’s search box. If you pasted a Fediverse handle, C.IM uses WebFinger to resolve it. Then C.IM fetches the actor document and learns where that actor receives activities.

When you click Follow, C.IM sends a Follow activity to the P.LU actor. After the relationship is accepted, future uploads can be delivered as ActivityPub activities. A new video on P.LU becomes a Create activity containing the video object, and C.IM receives it in the relevant inbox.

From the user’s side, the result is simple: a PeerTube upload appears in a Mastodon timeline. From the operator’s side, the useful part is even simpler. We do not need a private C.IM-to-P.LU bridge for this. Both services already speak the same protocol.

R.NF uses the same general idea through Lemmy. Lemmy is built around communities and threads rather than timelines and channels, so the interface feels different, but the federation model is still ActivityPub.

Scale, with a little caution

ActivityPub is no longer a lab demo. W3C’s 2018 announcement already mentioned more than one million registered Mastodon users across thousands of instances. After Elon Musk’s October 2022 Twitter acquisition, public statistics summarized by ThinkImpact describe Mastodon monthly active users jumping from the hundreds of thousands to more than 2.5 million by late 2022.

The network did not stay at that peak, which is worth saying plainly. A May 2026 snapshot from The World Data puts Mastodon monthly active users around 750,000 to 1 million, with more than 10.5 million registered accounts, 10,475 active instances, and more than 1.18 billion posts. The same page estimates more than 11 million registered accounts across the wider Fediverse.

These numbers are not exact. Fediverse statistics come from crawlers, opt-in reporting, and public instance data. Servers appear, disappear, block crawlers, misreport, or simply stop publishing useful counts.

Federated Works makes that caveat explicit while summarizing data from Fediverse Observer and related sources. Its January 17, 2024 snapshot listed about 13.7 million users, 3.5 million active users, 1.2 billion posts, and 22,456 reporting servers.

The rough order of magnitude matters more than the exact row in a table. ActivityPub is big enough that operators run into real caching, moderation, queue, and compatibility issues. It is also visible enough that larger platforms have had to respond. Threads began limited ActivityPub federation work in 2024, and 2025 reporting still described that work as expanding but incomplete. Standards tooling is still moving too; the public ActivityPub summary records Germany’s Sovereign Tech Fund supporting a compliance test suite with EUR 152,000 in 2023.

The parts that still annoy people

ActivityPub gives servers a common language. It does not make every Fediverse product feel perfectly joined up.

Account migration is the obvious example. Mastodon’s account moving documentation says a profile move can transfer followers if the remote software supports the Move activity. Posts do not move. Follows, blocks, mutes, and bookmarks need separate export and import steps. Moving followers is useful, but it is not a full account clone.

Remote conversations can also look incomplete. In a Mastodon discussion about missing replies, a maintainer explained that Mastodon does not guarantee it has every reply to every remote post. Fetching every possible conversation would create a lot of extra traffic. The user-facing version of that tradeoff is familiar: stale counts, missing replies, or a thread that looks fuller on one instance than another.

Usually, that points to implementation and synchronization rather than a protocol that cannot carry the data. Users do not care much which layer is at fault when a reply is missing.

The standards process has its own friction. A W3C Recommendation is stable, which operators like. Changing it is slow, which developers notice. Much of the Fediverse advances through extensions, implementation practice, and community convention before it feels standard.

Why instance choice still matters

ActivityPub lowers the cost of leaving a single company’s social graph. It does not remove trust from the system.

Your home instance still matters. Its admins set moderation policy. Its infrastructure handles your account, media, queues, backups, and abuse reports. Its jurisdiction and operating model matter too, especially if you care about privacy and long-term access to your own social identity.

For Owl Owl OÜ, C.IM, P.LU, and R.NF belong in the same story. They are not one giant app. They are separate services for microblogging, video, and discussion, hosted in the EU and built around open-source software that can participate in the same network.

The practical point is modest, which is probably the best way to state it. A post, a video, and a discussion thread do not have to live inside one corporate product to be connected. ActivityPub is the boring machinery that makes that possible.