The most important debate in social media right now is not happening on social media. It is happening in GitHub repositories, developer forums, and protocol specification documents, and it concerns a question that sounds technical but is fundamentally political: who should control the infrastructure of public conversation?
The two main contenders in what enthusiasts call the open social web are ATProto — the protocol underlying Bluesky, developed with early funding from Twitter — and ActivityPub, the W3C-recommended standard that powers Mastodon, PeerTube, Lemmy, and increasingly, Meta's Threads. Both claim the goal of decentralization. Both have vocal advocates who argue the other approach is either insufficiently open or practically unworkable. And both reflect genuinely different philosophical answers to the question of how power should be distributed in a social network.
Understanding the difference matters not just for the small community of developers and researchers who have been arguing about it for years, but for anyone who cares about what the next generation of public communication infrastructure looks like — because one or both of these approaches will shape it.
The Core Difference, Without the Jargon
ActivityPub, which became a W3C recommendation in 2018, is built around a model of federated servers. Each server — called an instance — is independently operated and stores the accounts and data of its users. When you post on a Mastodon instance, your post lives on that server. When someone on a different instance follows you, the two servers exchange messages to keep each other updated. The metaphor is email: any email provider can send mail to any other email provider because they all speak the same protocol, even though the servers themselves are completely independent.
The key implication of this model is that your identity and data are tied to the instance you chose. If that instance shuts down, you lose your account unless you migrated it before closure. Instance operators have significant power over their users: they can see your data, modify federation behavior, and ban you. The community of instance operators is diverse — thousands of independent servers hosted by individuals, nonprofits, universities, and activist groups — but the power within each instance is concentrated in the hands of its administrators.
ATProto takes a different architectural approach. Rather than a federation of independent servers, it is designed around what its creators describe as a separation of concerns: your identity, your data, and the applications that display and filter that data are all separate layers. Your identity on ATProto is a decentralized identifier that you own and can port between hosting providers. Your posts are stored on a Personal Data Server that you can operate yourself or entrust to a hosting provider. Relay servers aggregate content from across the network. AppViews — the layer that most users interact with through Bluesky — filter and display content according to their own logic.
The key implication is portability. In theory, if Bluesky as a company disappears, your identity and data survive because they are not owned by Bluesky — they are hosted on a PDS that you control. New AppViews can emerge and compete for users without controlling underlying data. Algorithms and feeds become modular: you could theoretically use multiple different AppViews on the same underlying social graph.
Why Mastodon Users Were Suspicious of ATProto
When Bluesky began federating its network in 2024 and developers started building bridges between ATProto and ActivityPub, the reaction from parts of the Mastodon community was more hostile than many expected. Understanding why illuminates something important about the different communities and values that have formed around each protocol.
Mastodon and the fediverse more broadly attracted users who valued the ability to set their own community norms, operate their own infrastructure, and choose who they federated with. The instance model, with all its limitations, gave users and administrators a meaningful degree of control over their information environment. Many Mastodon users had left mainstream social media precisely because they wanted a context where their communities were not subject to algorithmic manipulation or the decisions of a corporate owner.
The concern with ATProto bridging was essentially a version of consent: users who had chosen the fediverse had made an implicit choice about the context in which their posts existed. A bridge that made their content visible on Bluesky's network without explicit opt-in felt like a violation of that context. The analogy to early blogging culture is apt — there was a period when bloggers wanted to be public to their community while being uncomfortable with the idea of being indexable by anyone, anywhere.
This is a values conflict, not a technical one, and it points to the deepest difference between the two protocol communities. ActivityPub tends to attract users and developers who prioritize community sovereignty and the right to opt out of federation. ATProto tends to attract users and developers who prioritize portability and the ability to carry their identity and audience across different services.
The Centralization Question
Critics of ATProto have argued that whatever its theoretical decentralization architecture, in practice Bluesky PBC — the company — retains substantial control over the network. The relay infrastructure that aggregates content from across the network currently operates centrally. The BGS (Big Graph Service), which maintains the global firehose of all public posts, is run by Bluesky. The AppView that most users experience is Bluesky's. The DNS-based identity system has its own centralization dynamics.
These critics have a point, and Bluesky's team has not entirely disputed it. The honest version of the ATProto pitch is that the potential for decentralization exists in the architecture — the chokepoints are there by practical necessity while the network matures, not by design intent. Whether independent relay operators, PDS hosts, and AppViews will emerge at sufficient scale to make the decentralization real is an open empirical question that 2026 is beginning to test. One prediction from open social web observers for this year is that the first fully independent ATProto stack — operating PDS, relay, and AppView without dependency on Bluesky's infrastructure — will achieve viability.
ActivityPub advocates point out that their protocol has been producing genuine decentralization for years: there are thousands of independently operated instances, genuine community diversity, and real resilience against single points of control. They are not wrong, but ActivityPub's federation model has its own centralization dynamics — Mastodon.social, the flagship instance operated by Mastodon gGmbH, is enormous relative to the rest of the network, and many smaller instances depend on larger relay services for performance.
The uncomfortable truth is that both protocols have structural tensions between their decentralization ideals and the practical realities of running social software at scale.
What Interoperability Could Mean
The most interesting development of 2025 was the quiet normalization of cross-protocol bridging. Bridgy Fed, the third-party bridge built by independent developer Ryan Barrett, moved through controversy to something approaching acceptance as it refined its consent and opt-in mechanics. The discourse that was predicted to be contentious when Bluesky users were bridged to ActivityPub by default turned out to be far less explosive than anticipated.
This normalization matters because it suggests a possible future where ATProto and ActivityPub are not competing protocols but complementary layers of an open social web — where your identity on one network can reach audiences on the other, where content can flow between systems with different moderation philosophies, and where users are not forced to choose between the communities on each protocol.
That future requires both protocol communities to solve hard problems around consent, data portability, and the communication of context across network boundaries. But the technical barriers to interoperability are not fundamental — they are engineering problems, not logical contradictions. The social and values-based barriers are more significant, and they will require ongoing negotiation rather than a technical fix.
Why This Matters Beyond the Developer Conversation
The protocol debate might seem like a niche concern — the kind of thing that matters to a few thousand developers and researchers but has no bearing on the 400-plus million people using X or the billions using Meta's properties. This underestimates what is at stake.
The infrastructure decisions made in open-protocol communities in 2024 and 2025 are likely to become the defaults for a significant portion of online public conversation over the next decade, in the same way that email's protocol choices in the 1980s still shape how electronic communication works today. The question of whether social media identities are portable, whether algorithms are modular and replaceable, whether content can flow across systems with different rules — these are not abstract technical questions. They determine whether users have genuine alternatives when a platform degrades, whether communities can set their own moderation standards without losing access to wider networks, and whether the companies that build social media have the kind of lock-in that makes meaningful exit impossible.
ATProto and ActivityPub are working toward different answers to these questions. Neither has yet proven its approach at the scale of mainstream social media. But the experimentation happening in these communities right now is the most serious attempt anyone has made to build social infrastructure that does not concentrate all of its power in a single company.
That is worth paying close attention to, regardless of whether you have ever set up a Mastodon instance or thought about what a Personal Data Server is.
