Run down windows

FR#160 – Everyone Wants Servers And Nobody Wants Servers

What makes a social network resilient?

I also run a weekly newsletter, where you get all the articles I published this week directly in your inbox, as well as additional analysis. You can sign up right here, and get the next edition this Friday!

Recently, both Bluesky and the mastodon.social server were hit with DDoS attacks. The Bluesky DDoS took down most of the network for a full day, and the mastodon.social ddos took down the largest server (accounting for roughly 30% of the network) for a few hours. Lots of people seemed to have a great time, as the DDoS attacks proved fertile grounds for a ton of discourse in which everyone could demonstrate their priors over how open social networks should function.

Discourse on how these new open social networks should function are often framed in terms of ‘decentralization’, but I think that term has become a container that people can just project any property they like upon. In the context of the recent DDoS attacks it is more productive to talk in terms of resilience, where network decentralization is just one of the ways in which a network can be made resilient against attacks. So what makes a network resilient? What actually caused the difference between the Bluesky DDoS, where the microblogging part of the network was unavailable for over 99% of its users, compared to some 30% of the microblogging side of the fediverse? A straightforward reading would point to the network topology of the fediverse, that there are tens of thousands of servers on the fediverse, whereas there are only a few “servers” (whatever server means in atproto), which is furthermore dominated by the presence of Bluesky PBC. I don’t think this reading is wrong per se, but I think more can be said on it.

Talking about resilience allows us to make it clearer what we parts we are actually talking about. The first observation is that there is often a continous switching of going on: is the software resilient or is the network resilient? The fediverse network turned out to be pretty resilient against a DDoS attack, but that is taking the perspective of the entire network. My account on mastodon.social was simply inaccessible during this time period, so while it’s great that the network is resilient, my doomscrolling session was interrupted all the same.

This results in some strange situation: people care about network resilience because the people involved in building open social networks largely do so from a belief that open social networks can create a better social internet than the current Big Tech platforms can. But ‘network resilience’ is not a thing that can exist by itself, it is an emergent property from many independent services being resilient (or in the case of mastodon.social and bsky.app this week, not being resilient). For most people, network resilience is something they rarely think about, they just want their app to work.

The second observation is that there is a difference between what a protocol permits regarding resilience, and what a system exhibits resilience, and the connection between protocol specification and how a system functions in practice is surprisingly loose, for both the fediverse and the atmosphere.

For the fediverse, resilience comes from the fact that there are tens of thousands of servers all interoperable with each other. But the Activitypub protocol specification does not even mention the concept of servers or instances. ActivityPub is a protocol that specifies how Actors can send each other messages. Specific implementations such as Mastodon used this protocol to build twitter-like software that anyone could run for themselves. Because other people could run other ‘instances’ of the same software, servers emerged as a concept from a protocol that did not specify it. And because many servers appeared, ‘network resilience’ appeared as an emergent property of this network of connected servers.

For atproto and the atmosphere, somewhat of the opposite happened. Bluesky places a high priority on building a resilient platform, with their emphasis on concepts like credible exit, which allow people to leave Bluesky and join another platform any time they want, without anyone’s permission. Furthermore, atproto disintermediates many different aspects of a social network into separate components that can all be run independently and switched out. Instead of a single server that is responsible for data storage, identity, moderation, data aggregation, feed generation and more, atproto splits these up into independent parts. Splitting up a system into parts that can all be swapped out for other parts, and all have all of these parts be independently operated, are design decisions that align well with making a system resilient.

This is a strange situation.

The protocol that did not design for a resilient network, and did not even specify the entities that cause the network to be resilient, turn out to currently be fairly resilient to DDoS attacks, while the protocol that does explicitly design for resilience turns out not to be.

Part of the explanation here is to see this as a function of a specific moment in time.

The fediverse saw a massive inflow of new users, and people starting new servers, in late 2022 and early 2023 after Elon Musk took over Twitter. That wave however has largely died down. In the last 36 months, only 3 new Mastodon servers with over 1k monthly active users have appeared. There are 38 servers that are less than 3 years old and have more than 100 monthly active users, the rest of the 480 Mastodon servers with over 100 monthly active users is all older than 3 years. In other words, the current topology is being held up by the admins that joined the fediverse during or before the 2022 wave. There is still a small trickle of new admins, but it is small enough that the network is not really replacing its operator base so much as slowly drawing from the one it already has.

Bonfire is a new fediverse platform that provides some major improvements over Mastodon, such as a Google+-like circles feature, granular boundary controls per post, support for long-form blogging, and more. Its release has drawn major attention and encouragement in the fediverse. But while Bonfire has all the features profess to want in a fediverse server, nobody is actually running a Bonfire server. The 50-ish Bonfire servers that exist are either testing or one-person servers. Bonfire’s situation shows that the bottleneck is not a technology problem or a feature problem. If better software were what the fediverse needed to produce new servers, Bonfire would be producing them. Bonfire has the features and the enthusiasm, but what it does not have is people willing to run servers on it.

Together this shows that the network resilience that the fediverse shows is a contingent effect of a specific moment in time, from an earlier fediverse and the acquisition of Twitter by Elon Musk. This caused many new fediverse servers to start. But for a network of many servers to stay resilient a continuous inflow of servers is needed as well, and it is very unclear which communities or institutions will provide this inflow of new fediverse servers.

For the atmosphere, the software to build decentralized digital places is all there and available. But it is much less clear what the organizational structures should be to run these digital places, and the groups working on it are taking different approaches.

For Gander, that means building a Canadian network, where connection to Bluesky is an opt-in setting, and where the organization is funded via community investments. Gander is making a bet that the atmosphere can be organized around national-cultural identity. The opt-in federation is the core of it: Canadian users should not automatically see the global network unless they choose to, which makes Gander a distinctly Canadian place rather than a Canadian-flavored slice of Bluesky.

For Blacksky, that means building communities, and their most recent feature, Acorn, goes even further in this direction, letting people create their communities on Blacksky. The Blacksky organization uses a people’s Assembly for collective decision making. Blacksky is focusing on community and governance. The Assembly makes collective decisions, and Acorn lets people form communities on Blacksky itself, which turns Blacksky into the substrate for a federation of communities rather than a single community.

Eurosky just launched Eurosky Portal, and positions itself as an entry point to the atmosphere. The organisation is trying to sustain itself via crowdfunding and leans into Europe’s digital sovereignty movement for funding. Eurosky, just like Gander, is targeting regional values and digital sovereignty. The bet is that a European atmosphere, funded by Europeans and accountable to European values, is a meaningful institutional form even without yet having its own appview.

Taken together, these three organizations show that the institutional question in the atmosphere is still open. There is no atmospheric equivalent yet of the de facto consensus the fediverse developed around what a Mastodon instance is for, and the three projects are making three different bets about what organizational shape legitimate atmospheric institutions should take.

The open socials movement has a tendency to fall into protocol eschatology. Soon, many people and organisations will start new fediverse instances. Soon, alternative appviews for Bluesky will emerge as the ecosystem matures. But this viewpoint treats the future success of open protocols as guaranteed, a latent state, rather than as something that has to be produced by specific actors doing specific work. Eschatological framings all share a structure: they locate causation somewhere other than individual human decisions, where protocol adoption will happen because the protocols are good, and institutional forms will emerge because ecosystems mature. Each of these viewpoints removes the question of who actually does the building, which is precisely the question that determines whether the building happens at all. The fediverse’s current resilience was produced by people, who in a specific moments in time decided to run servers.

I find myself tempted by eschatological framings too, which is part of why I want to resist them explicitly. It is much easier to believe that new fediverse servers will arrive eventually, or that alternative appviews will materialize as the atmosphere matures, than to figure out what the new institutions that are needed to build a better social internet actually look like. Networks become resilient when people decide to actually build them. And it seems that the main open question is: what will be the shape of the organisations that will actually build the future of the social internet?

This article was sponsored by a grant from the NLnet foundation. 

This article was sponsored by a grant from the NLnet foundation. 

Connected Places is a labor of love. Want to support the work I’m doing? You can click here to donate, or scan the QR code.

That’s all for this week, thanks for reading! If you want more analysis, you can subscribe to my newsletter. Every week you get an update with all this week’s articles, as well as extra analysis not published anywhere else. You can subscribe below! Follow on Bluesky: this blog:  @fediversereport.com and my personal account: @laurenshof.online.