I keep seeing people hold up Mastodon as the shining example of true decentralization whenever discussions about Bluesky’s centralized nature come up. While I understand the appeal of this comparison, the reality is more complicated than most people realize. Mastodon, despite its federated architecture, operates in ways that make it far less decentralized than its supporters claim.

The most obvious issue lies in how users actually experience Mastodon. When someone decides to join, they face an immediate barrier: choosing a server. This single decision fundamentally shapes their entire social media experience. Unlike truly decentralized systems where users can participate equally regardless of their entry point, Mastodon users find themselves constrained by their server choice in ways that persist throughout their time on the platform.

Most newcomers, overwhelmed by the choice or simply wanting to get started quickly, end up joining mastodon.social. This flagship instance is owned and operated by Eugen Rochko, the creator of Mastodon itself. The concentration of users on this single server creates a situation remarkably similar to what Mastodon advocates criticize about centralized platforms. Having a large portion of users on mastodon.social is functionally equivalent to everyone being on X.com or bsky.app, just with extra steps and a federated label attached.

Server administrators also wield enormous power over their users. They can unilaterally decide to defederate from other instances, effectively cutting off their users from entire communities and conversations. These decisions most often happen without user input or consent. A person might wake up one day to discover they can no longer interact with friends or follow accounts they care about, simply because their server admin had a disagreement with another server’s policies.

Content moderation presents another layer of centralization. Each server operates according to its administrator’s vision of acceptable behavior and speech. Users must conform to these rules or face suspension or removal. This creates isolated pockets of discourse rather than a truly open network where ideas can flow freely between participants.

The technical infrastructure reveals even deeper centralization issues. Most Mastodon servers rely on a handful of major hosting providers and content delivery networks. When these services experience outages or policy changes, large portions of the Mastodon network become inaccessible. The supposed redundancy of federation disappears when multiple servers depend on the same underlying infrastructure.

Running a Mastodon server requires technical knowledge, ongoing maintenance, and financial resources. This barrier to entry means that most users cannot practically participate as equals in the network. Instead, they become dependent on the goodwill and continued interest of server operators who may abandon their moderation efforts or instances at any time, taking user data and connections with them.

Migration between servers, often touted as a solution to these problems, works poorly in practice. Users can move their follower lists, but they lose their post history, replies, and the context of their previous interactions. The process is cumbersome enough that most people never attempt it, effectively locking them to their original server choice.

The development and direction of Mastodon itself remains centralized around a small core team. While the software is open source, the practical reality is that most servers run the official Mastodon software and follow the development decisions made by this central group. Alternative implementations exist but have minimal adoption, meaning the network’s evolution depends on choices made by a few key developers.

Federation also creates unexpected forms of inequality. Popular servers with many users and good connections become more valuable to join than smaller, isolated instances. This network effect concentrates users on a relatively small number of well-connected servers, undermining the distributed nature that federation was supposed to enable.

The user experience itself reflects these centralization pressures. Finding and following people across servers remains clunky compared to centralized platforms. The local and federated timelines create server-centric views that encourage users to think in terms of their particular instance rather than the broader network.

None of this means Mastodon lacks value or that federation provides no benefits over completely centralized platforms. The ability to choose among different moderation policies and communities has real worth. However, calling Mastodon truly decentralized misrepresents how the network actually functions and what users experience when they use it.

When people point to Mastodon as proof that decentralized social media works while criticizing Bluesky for being centralized, they’re making a comparison based more on aspiration than reality. Both platforms involve significant centralization in different ways. Part of the confusion stems from conflating Mastodon the software with the broader fediverse ecosystem. The ActivityPub protocol that powers federation does enable genuinely decentralized possibilities, such as allowing individual websites to federate with social networks. However, Mastodon as it’s actually used and experienced by most people doesn’t deliver on these broader decentralized ideals.

Acknowledging this doesn’t diminish the legitimate advantages that federated systems can offer, but it does help us have more honest conversations about what these technologies actually deliver in practice versus what they promise to provide.