Mastodon case study: how independent servers formed one social network

Mastodon is often described as an alternative to Twitter, but its most important case study is architectural. Instead of placing every account, post, and rule inside one service, the project provides software that organizations and communities can use to operate their own servers. Those servers, commonly called instances, exchange activities and form a shared network.

The project began in 2016 under creator Eugen Rochko and launched publicly that October. Its code is distributed under the AGPLv3 license. This allows people to inspect, modify, and host the server, while requiring corresponding source code to be made available when a modified version is offered as a network service. The official organization says Mastodon is developed as a nonprofit initiative and began moving toward a foundation with community governance in 2025.

The central decision was to separate software from the network

A Mastodon server stores its members’ accounts, enforces local rules, and provides the publishing interface. It does not need permission from the main project to exist. At the same time, its users can follow people on other servers, in a model comparable to communication between different email providers.

This separation prevents “Mastodon” from meaning one website. The project operates large servers such as mastodon.social, but they are only participants in the federation. A university, collective, or company can run another domain under its own policy. If the central project disappears, existing installations do not automatically shut down; if an individual server closes, however, the accounts it hosts remain exposed to that local decision.

The design echoes a lesson from other community infrastructure. Just as OpenStreetMap separates its shared database from the many maps and services built on top of it, Mastodon separates server software from the social network produced through interoperability.

ActivityPub provides the common layer

Federation depends primarily on ActivityPub, a protocol based on ActivityStreams 2.0 and JSON-LD. The standard defines a client-to-server API and a server-to-server API. In the latter, each account is represented as an actor with an inbox and an outbox. Actions such as creating a post, following someone, liking, or sharing are delivered between addresses identified by URLs.

Mastodon already existed when ActivityPub became a W3C Recommendation on January 23, 2018. Adopting a standard outside the project expanded the consequences of its architecture: the remote side does not have to run Mastodon. Any compatible software can participate in the same social graph, although specialized features may require extensions or adaptations.

Interoperability does not mean that every product behaves identically. Mastodon’s documentation lists extensions for account migration, reports, polls, sensitive content, and quote controls. A server may recognize only part of those capabilities. Common protocols create a basic language; they do not turn different implementations into the same application.

Moderation is no longer one universal policy

On a centralized platform, one company publishes a general policy and enforces sanctions. On Mastodon, administrators can moderate local members and limit or suspend entire domains. One community can refuse interaction with another without taking the rest of the network offline.

A preliminary study published on arXiv in June 2026 examined one year of instance relationships and daily blocking decisions. Its authors found structural stability despite continuous moderation activity and concluded that decentralized blocks can isolate domains regarded as incompatible without a single controller. Because the paper is a preprint, its findings should not be treated as settled consensus. It also identified echo-chamber effects, showing that local autonomy can restrict information flow.

What the Mastodon case demonstrates

The project’s technical achievement is not the elimination of administration, cost, or conflict. Every server still needs hosting, updates, abuse protection, backups, and responsible operators. Decentralization distributes those duties among many administrators and lets communities decide whom they will connect with.

The trade-off is clear. There is no single owner capable of changing the entire network with one decision, but there is also no single team capable of solving every problem. Mastodon demonstrates that a social network can be organized as interoperable infrastructure. Its durability depends less on one application than on the combination of open code, a public protocol, and local institutions willing to maintain the system.