Imagine if you could not send emails from Gmail to Outlook users. Or imagine that you could only open Google websites in Chrome and Mozilla websites in Firefox. It would be absurd, yet this is exactly how social media works today. You cannot follow a Mastodon account on X, nor watch a PeerTube video on TikTok. You cannot comment on a Pixelfed photo from Instagram. Every platform is a walled city. Your audience, your posts and your reputation are all trapped inside by design.

Two open protocols are trying to change this: ActivityPub, a W3C standard since 2018, powers the Fediverse — a network of millions of users across thousands of independent servers running Mastodon, PeerTube, Pixelfed, Lemmy and more. The AT Protocol, created by Bluesky and launched more recently, takes a fundamentally different approach, focusing on account portability and algorithmic choice. Together, these protocols represent the most serious attempts yet to build social media as open infrastructure rather than corporate silos.

ActivityPub and the Fediverse

ActivityPub is built around three core concepts: actors, activities and objects. An ‘actor’ is anything that can perform an action — typically a user, but also a group, bot or application. An activity is something an actor does, such as creating a post, following someone or liking an object. An object is the thing being acted upon, such as a note, an image, a video or an event.

Every actor has two endpoints: an inbox and an outbox. The outbox publishes the actor’s activities. The inbox receives activities from other actors. When Alice follows Bob, her server sends a ‘Follow’ activity to Bob’s inbox. Bob’s server processes this and sends an ‘Accept’ activity back to Alice’s inbox. When Bob posts, his server delivers a ‘Create’ activity to the inboxes of all his followers. All of these are plain HTTP POST requests carrying JSON-LD documents. To find Alice’s actor endpoint, your server queries the WebFinger endpoint at https://example.com/.well-known/webfinger and receives a JSON response.

The protocol is simple in principle, but more flexible in practice. JSON-LD adds linked data annotations that most implementations ignore. Although different servers — such as Mastodon, Pleroma, Misskey and GoToSocial - all speak ActivityPub, they occasionally fail to render each other’s posts correctly because they handle edge cases differently. Nevertheless, the protocol works. Millions of people use it every day, and server-to-server federation is reliable because it runs on the same technologies as email: HTTP, DNS and TLS.

The Fediverse - a network of servers that speak ActivityPub - is not a single platform. Mastodon handles microblogging in a way that is similar to X, while PeerTube uses WebTorrent for video sharing and distributed bandwidth. Pixelfed is a federated Instagram. Lemmy and Kbin handle link aggregation in a similar way to Reddit. WriteFreely and Plume provide long-form blogging. Funkwhale streams music. Mobilizon manages events. All of these platforms can interact with each other because they all use the same protocol. For example, a Mastodon user can follow a PeerTube channel. A Plume post can be liked on Pixelfed. The protocol does not discriminate between different applications.

While this cross-application interaction is the Fediverse’s greatest strength, it can also be a source of friction. For example, a Mastodon timeline is designed for short text posts, not hour-long video thumbnails. A PeerTube comment section expects video context, which a Mastodon reply does not provide. While the protocol connects everything, each application interprets the data through its own interface. While this is a solvable problem — it is a user interface challenge, not a protocol limitation — it is currently the main issue that users encounter.

The instance model and its limits

Every Fediverse user belongs to an instance, and their username is in the format @username@instance-domain. While this model is democratic in theory — in that anyone can run an instance — it creates three tensions in practice.

The first is moderation. Each instance sets its own rules. If one server refuses to moderate hate speech, for example, others can defederate from it, thereby blocking all content from that server. While this self-governance through mutual exclusion is effective, it means your experience depends entirely on your instance administrator. A well-moderated instance is pleasant. A poorly moderated one is not. If your admin abandons the server, you must migrate.

Centralisation is the second option. Running an instance requires time, money and skill. Most people join large instances run by someone else. The largest Mastodon server has hundreds of thousands of users. If it goes down, a significant part of the network becomes inaccessible. If it defederates from your small instance, you lose access to a large part of the conversation. The network is technically distributed, but practically concentrated.

The third and deepest problem is identity portability. When you switch servers, you can redirect your followers, but your old posts are left behind. If the old server disappears, your history disappears with it. This is the issue that email solved in 1982 — if you own your domain, you can switch email providers and keep your address — but ActivityPub has never implemented portable identity. As a result, users are incentivised to pick large, stable instances that are unlikely to shut down, which reinforces centralisation.

AT Protocol - solving the identity problem

The AT Protocol, created by Bluesky, was designed from the outset to solve the identity portability issue that ActivityPub failed to address. The architecture separates concerns into three layers.

At the base is the Personal Data Server (PDS). This is your server — the machine that stores your posts, likes, follows and everything else you create. A PDS is a simple REST API server that cryptographically signs all your publications. You can run your own PDS, use a hosted provider or let Bluesky run one for you. The key property is that the PDS is replaceable. Your data is stored in a portable format and can be moved to a different PDS at any time.

Above the PDS sits the relay. This is a firehose aggregator that connects to multiple PDS instances, collects all their public events and republishes them as a single, merged stream. The relay does not store data; it indexes and forwards information, like a search engine crawler.

On top of the relay are app views. These consume events from the relay, process them and serve them to applications via a structured API. The Bluesky app view provides the feed, thread view and notifications that you see in the client. However, the architecture allows for competing app views. For example, a third party could build an app view with different moderation policies, ranking algorithms, or content filters, all of which would draw on the same relay data.

The final piece is custom feeds. A feed is a saved search of the firehose. Anyone can create one, for example for posts containing specific keywords, posts from a curated list of accounts or popular posts in a particular language, and then publish it. Users can then subscribe to the feeds they want. This transforms algorithmic curation from a corporate black box into an open marketplace.

The killer feature is account portability. The AT Protocol uses DIDs (Decentralised Identifiers), which are a W3C standard. Your DID resolves to a DID document listing your current PDS and your public keys. When you move to a new PDS, you simply update the DID document. Your followers then resolve your DID, discover the new server and continue to follow you. As your posts are cryptographically signed with the same key, their authenticity can be verified regardless of which PDS hosts them.

The handle system adds a human-readable layer. Your handle — for example, @user.bsky.social or your own domain — is a DNS record that points to your DID. You can change your PDS without changing your handle. You can also change your handle without changing your identity. The DID is the stable root. This is fundamentally different from the ActivityPub model, where ‘@user@server’ permanently ties you to a hostname.

The AT Protocol also defines lexicons — machine-readable schema files that describe every record type, procedure and query. A lexicon for a post specifies the required fields, their types, and the constraints. These are not just documentation; they are used to generate client libraries, validate data and power code completion. This gives developers a reliable contract, providing a practical advantage over ActivityPub’s more loosely defined JSON-LD vocabulary.

Bridging the two protocols

The ActivityPub and AT protocols were designed independently, with different architectures. ActivityPub uses a push model, whereby servers actively deliver activities to inboxes. The AT Protocol uses a pull model, whereby app views query relays for events. ActivityPub objects are JSON-LD with a specific vocabulary. AT Protocol records are defined by Lexicon schemas. Yet they can communicate with each other.

Bridgy Fed is the bridge. It presents itself as an ActivityPub actor on the Fediverse side and as an AT Protocol PDS on the Bluesky side. When a Mastodon user follows a Bluesky user via Bridgy Fed, the bridge translates follow activities into AT Protocol follow records, and translates AT Protocol post events into create activities. The bridge maintains a mapping between Fediverse handles and AT Protocol DIDs, enabling identities to carry across the boundary.

However, the translation is imperfect. Likes, boosts, replies and quoted posts do not have exact equivalents on both sides. Moderation policies also differ — whose rules apply to a bridged post? While these are not insurmountable problems, they mean that cross-protocol interaction is functional but not seamless. A deeper challenge is semantic: a follow in ActivityPub is not the same as a follow in the AT Protocol. Bridging requires choosing one protocol’s semantics as authoritative and adapting the other to fit. The result is a lowest-common-denominator experience where advanced features are lost.

Despite these limitations, the bridge exists and works. If you run a Mastodon instance and want to follow someone on Bluesky, you can do so. This demonstrates the value of open protocols: it’s not about everyone using the same one, but about protocols exposing enough functionality to allow bridges to be built.

Running your own

The most common self-hosted option for ActivityPub is Mastodon, though it is more resource-intensive than lighter alternatives such as GoToSocial (Go) or Pleroma (Elixir). A small Mastodon instance requires a PostgreSQL database, Redis and several gigabytes of RAM. GoToSocial, on the other hand, can run on a Raspberry Pi. The best option for you will depend on how many users you plan to host and which features you need.

For the AT Protocol, Bluesky provides a Go-based PDS reference implementation that runs on a modest VPS. You will need a domain name for your handle and a TLS certificate. Once it is up and running, you can create an account on your PDS, set the DID document and configure the DNS. Your data is stored as CAR (content-addressed archive) files, so you can back it up and restore it elsewhere. The relay is the most demanding part, and most individuals will not run their own, but this is not necessary. Having someone else run a relay makes your data discoverable, just as having someone else run a search engine makes your website discoverable.

Where this leaves us

Of all the layers of personal infrastructure, social media is the hardest to reclaim. However, files, calendars and contacts can be transferred to DAV. Messaging can be transferred to Matrix or XMPP. However, social media involves public reputation, an accumulated post history and a follow graph representing years of relationship building. The switching cost is enormous, and walled gardens depend on this.

However, ActivityPub has proven that decentralised social networking can work on a large scale. Millions of people use it every day. The protocol is deployed, tested and stable. However, its identity model ties you to your instance, creating a centralisation pressure that undermines the promise of decentralisation.

The AT Protocol addresses this issue directly with DIDs and content-addressed storage. However, it is newer and less proven, and it has its own centralisation pressures — the Bluesky app view dominates, and relay infrastructure is expensive. However, the core innovation works: you can switch between providers without losing any data. This is a genuine solution to a problem that has kept social media centralised for two decades.

Neither protocol is the final answer. Both have rough edges. They both face challenges around moderation, sustainable infrastructure and adoption. However, they are currently the best solutions to the question of what happens when you treat social networking as infrastructure — something durable, interoperable and under the control of its users. They are protocols, not products. No company can kill ActivityPub. No acquisition can shut down the AT Protocol. The servers you run today will still work tomorrow, and the connections you build will remain yours.