The decentralised social web runs on protocols, and the two most significant ones in 2026 are ActivityPub (powering Mastodon and the fediverse) and AT Protocol (powering Bluesky). The differences between them are not superficial. They reflect genuinely different ideas about where identity should live, who controls data, and what federation actually means in practice. This matters whether you are building social applications, running an instance, or simply trying to understand why moving between platforms is harder than it should be.
ActivityPub: The Fediverse Standard
ActivityPub became a W3C standard in 2018. It defines how servers communicate to create federated social networks, and its design reflects the federated web thinking of that era: distributed servers, community-run instances, no central authority.
The architecture centres on what the spec calls actors. Every user - and some other entities - is an actor with an inbox and an outbox. When you post on Mastodon, your server sends that post to every server hosting one of your followers. Federation is essentially servers pushing messages to each other’s inboxes on behalf of their users. Your identity is tied to your instance (@user@instance.example), which means if your instance disappears, your identity disappears with it unless you have already migrated.
This design has real strengths. The ecosystem is broad: Mastodon, Pixelfed, Lemmy, and PeerTube all run on ActivityPub. The W3C process gives the specification formal governance and community input. The protocol itself is relatively straightforward to implement, which partly explains why so many different platforms adopted it. No central infrastructure is required - any server running compatible software can join.
The limitations are equally real. Moving an account between instances is a manual process that does not carry post history with it. ActivityPub does not prescribe data schemas, so different implementations handle edge cases differently and interoperability between, say, Mastodon and Lemmy is imperfect. Discovery across instances relies on hashtags and third-party relay tools rather than anything built into the protocol itself.
AT Protocol: Bluesky’s Foundation
AT Protocol - Authenticated Transfer Protocol - was developed by Bluesky and takes a different set of bets. Where ActivityPub assumes the instance is the unit of trust, AT Protocol assumes the individual user should own their data regardless of which provider hosts it.
The architecture has more layers. Your data lives in a Personal Data Server (PDS), which you can move between providers without losing anything. Your identity is a Decentralised Identifier (DID), independent of any server - so changing providers does not change who you are. Above the PDS layer, relays aggregate data from across the network, and AppViews (such as the Bluesky app itself) consume that relay data to build the actual user experience. This layered design is more complex but it is what makes the data portability story coherent.
AT Protocol also uses formal schemas called Lexicons to define data structures, which enforces consistency across implementations in a way ActivityPub’s looser model does not. Feed algorithms are another deliberate design choice: anyone can build and publish a feed algorithm, and users can choose which ones they use. Key rotation and account recovery mechanisms are built in from the start.
The trade-offs are significant, though. In practice, most users rely on Bluesky’s own infrastructure for relays and AppViews, which creates real centralisation risk despite the protocol’s portable design. Self-hosting the full stack is considerably harder than running a Mastodon instance. And as of 2026, AT Protocol remains primarily a Bluesky ecosystem - the protocol exists, but the breadth of platforms building on it does not yet compare to ActivityPub’s. Governance is also tighter: Bluesky PBC controls protocol development more directly than the W3C process does for ActivityPub.
Side-by-Side Comparison
| Aspect | ActivityPub | AT Protocol |
|---|---|---|
| Standard body | W3C | Bluesky PBC |
| Identity | Instance-based handle | DID (portable) |
| Data location | On your instance | In your PDS |
| Data portability | Account migration (partial) | Full data portability |
| Feed model | Chronological (server-decided) | Custom algorithms (user-chosen) |
| Federation model | Peer-to-peer between servers | Hub-and-spoke (relay + AppView) |
| Ecosystem breadth | Many platforms (Mastodon, Pixelfed, Lemmy, PeerTube) | Primarily Bluesky |
| Self-hosting complexity | Moderate | Higher |
| Discovery | Hashtags, relays | Global search, custom feeds |
| Moderation | Instance-level | Labeler services |
Different Values, Not a Hierarchy
The protocols reflect different priorities, and it is worth being precise about what those are.
ActivityPub prioritises instance autonomy, community governance, and a broad federation model. It trusts instance admins to make decisions for their communities, and that trust is structural - the protocol gives them the tools and gets out of the way. AT Protocol prioritises individual data ownership, algorithmic choice, and portable identity. It is trying to prevent lock-in at any layer, including at the protocol layer itself.
Neither approach is objectively better. Calling AT Protocol “better ActivityPub” is a category error - they optimise for different values and make different trade-offs.
Interoperability: Can They Talk to Each Other?
As of 2026, ActivityPub and AT Protocol do not interoperate natively. The data models are fundamentally different enough that a clean bridge is genuinely hard.
Third-party bridge services can translate between protocols, allowing some cross-platform following and posting. These bridges are imperfect - not all features carry across, and the experience degrades compared to native use. True interoperability would require either protocol-level adaptation or standardised bridge specifications. That is an area of active discussion, but it is not close to resolution.
For more on cross-protocol tools, see our articles hub.
What This Means for Developers
If you are building social applications, the choice has practical consequences. ActivityPub is the right choice if joining the existing fediverse ecosystem matters - the breadth of platforms and users is already there. AT Protocol is worth serious exploration if data portability and custom algorithms are core to what you are building, not afterthoughts.
Supporting both is possible, but it substantially increases implementation complexity - you are essentially maintaining two identity systems, two data models, and two federation architectures. Both protocols are also evolving, so staying current with their development is not optional. Our developer notes cover practical considerations for building on these protocols.
What This Means for Users
For everyday users, the protocol shapes the experience in four main ways. Which communities you can reach is the most obvious: ActivityPub gives you the broader fediverse, AT Protocol gives you the Bluesky ecosystem. How your data is handled differs meaningfully - AT Protocol’s portability guarantees are stronger by design. What your timeline looks like is shaped by the feed model: AT Protocol offers algorithmic choice, ActivityPub defaults to chronological feeds as decided by your server. And migration paths differ - ActivityPub moves you instance to instance, AT Protocol moves your PDS to a new provider.
Common Mistakes
A few misconceptions come up repeatedly when people discuss these protocols.
Assuming one protocol will eventually win and the other will fade is probably wrong. Both serve real needs and will likely coexist for years. Treating AT Protocol as a superior version of ActivityPub misreads what each is trying to do - the design trade-offs are genuinely different, not better or worse on some shared scale.
Ignoring the ecosystem around a protocol is also a mistake. A technically elegant protocol with no meaningful user base is less useful than a good-enough protocol with a large, active community. Confusing the protocol with the platform compounds this: Mastodon is one ActivityPub implementation, Bluesky is one AT Protocol implementation, and neither defines what the protocol is capable of.
Finally, expecting seamless cross-protocol interoperability any time soon will lead to disappointment. Bridge quality will improve, but native cross-protocol federation is not on the near-term horizon.
Frequently Asked Questions
Can I use both Mastodon and Bluesky? Yes. Many people maintain accounts on both. They are independent platforms with independent accounts, and there is no technical barrier to using both.
Will Mastodon adopt AT Protocol? Unlikely. Mastodon is built on ActivityPub and its community values align closely with that protocol’s design. Some interoperability through bridges is more realistic than a full protocol shift.
Which protocol is more “decentralised”? This depends on what you mean. ActivityPub’s peer-to-peer model is more decentralised in architecture - no hub required. AT Protocol’s data portability is more decentralised in terms of user empowerment - your data is not stuck with a provider. Both claims are defensible.
Can I build an app that supports both? Yes, but it requires implementing both protocols and handling the differences in data models, identity, and federation. Some projects are attempting this. See our tools page for cross-protocol tools.
Is one protocol more private than the other? Both protocols make public content public. Privacy depends more on how a platform implements the protocol than on the protocol itself. Our best tools guide covers privacy-focused options.