Mastodon Systemic Sustainability
hosting costs breakdown, scaling concerns, problem user management, and one solution
Many thousands of new mastodon users have flooded onto the platform, with hundreds of instances being set up in just under a week. Many users have begun asking questions about who hosts their instance and if their moderation preferences really align with user interests. Many administrators will soon be getting hosting bills and thinking about ways to cover costs. These two issues are just some of the bottom-up and top-down pressures that mastodon will experience in the coming months. We’ll briefly go through some direct monetary costs of running a mastodon instance, moderation issues and common solutions, and finally present a novel way of addressing both issues with one policy.
Hosting Cost Projections
There are two hosting related costs associated with running a mastodon instance, servers and bandwidth. Both types of cost increase as instance usage increases, which can incentivize administrators to make decisions that run counter to the wishes of their users.
Server cost will be widely variant depending on the manner in which the instance is deployed. Some administrators will choose to deploy to a single host in an effort to keep costs down or to simplify administration. Some will deploy to multiple hosts or more powerful single hosts in an effort to provide a more responsive instance with higher uptime, but at increased monetary cost. Due to how widely server costs can vary I’ve excluded them from this analysis, however I believe total server costs roughly increase as instance use increases, regardless of the deployment strategy.
The other main cost is bandwidth, the bulk of which will be used transferring static assets to users and various other mastodon instances. Most instances will have separate systems to serve static and dynamic content. Because the bulk of the dynamic content is text and it will not be a high percentage of total bandwidth usage, it is assumed bandwidth costs for dynamic content are negligible. Static content is generally much larger in size and will take up the vast majority of total bandwidth cost.
Likely due to the ease of setup and administration, most instances seem to be using some combination of AWS S3 and AWS Cloudfront to store and serve static content. See below for some rough pricing estimates based on the following assumptions: 25 requests / user / day, 0.1 megabyte per request, and an extremely slight network effect modifier. For full formulas, view the Pricing Worksheet linked at the bottom of this post.
The largest mastodon instance at the time of this writing is mastodon.social with ~40k users, the next runner up being mastodon.cloud with ~15k. By my napkin math projections they’re spending about $270 and $100 respectively on static content hosting every month. This might not seem outrageous, but as instances grow this pressure will get worse. Many administrators have put donation systems of some kind in place in order to allow interested parties to give money towards hosting costs. The reliance on donations can lead to a sort of economic coercion or administrative bias where users with money to spare wield undue influence over those who don’t donate. This subtle effect is not dissimilar from the influence advertisers wield over twitter.
Problem Users
Now we’ll move on to a more visible and distributed problem, that of dealing with problematic/frequently reported users. Mastodon and its community provide multiple systems meant to address these users, such as user level blocking, instance wide muting, and inter-instance federation controls. There are many trade offs to be made here and no solution will be a 100% fix.
Mastodon natively provides functionality to allow users to block specific accounts. Blocking prevents the blocked user’s messages from appearing to the blocker anywhere on the instance. For some users this functionality will be sufficient to avoid unpleasant or unwanted interactions, but for others who are being specifically targeted I find it unlikely this functionality will address their issues. A common response to being blocked is to create another account and continue the interaction despite the blocker’s explicit intentions. Mastodon also provides administrative functionality to mute users for an entire instance and prevent their messages from being federated. This is effectively a “shadow ban” and is intended to contain the problem user without informing them of the containment, hopefully prolonging the period before they create another account. There is a clear tradeoff here between ease of access and ability for problem users to avoid penalties; as it becomes easier to sign up the penalty imposed by blocking or muting goes down. This tradeoff is simple to see at the intra-instance level, and a similar tradeoff occurs at the inter-instance level.
Communities across federated instances are finding norms and constructing rules that allow them to meet their diverse and varying user preferences. We will see predominantly two approaches to keeping instances with incompatible moderation preferences from causing problems for one another: whitelists, and blacklists. While these aren’t the only two approaches, they are both easy to imagine and are currently seeing use in the wild. Communities will need to decide how they would like to manage the tradeoff between ease of access and growth vs having a greater ability to curate and manage their experience.
The whitelist approach does not allow open federation by default, but seeks to build a community where all instances meet some shared standard rules and are expected to cross-enforce those rules where necessary. Whitelists should spring up predominantly in communities with strong shared identities and a history of perceived persecution or oppression. These communities generally feel a much stronger need to prevent unwanted communication than more diverse and varied communities, and they are often targeted more frequently by persistent or ideologically motivated users looking to cause offense. If this becomes the predominant mode of federation control, expect the balkanized mastodon to feel much more like the individual special interest forums that are available online today, and less like a global real time social network. Note that no particular approach is being moralized here one way or the other, it’s merely a consequence of fewer users generally meaning less activity.
The blacklist approach is to allow open federation, and then handle problem instances on a case by case basis. This is currently the default mode of operation for mastodon and allows for anyone to create an account on any instance and message users on other open instances. Expect various centralized public blacklists based on instance/community ideology to be used and maintained. Questions of ideology or administrative preference will primarily be discussed and handled within each local community. There are myriad approaches to meeting community needs and we will continue to see this space evolve as the tech, norms, and community all influence each other.
Generally, if the administrators actions align with community interests, we should be prepared to call that instance functional or sustainable. When administrators take actions that run contrary to the wishes of their user base, then we’re back in the twitter scenario but with the added caveat that users can now easily leave for another instance and continue communicating with their friends. Among the solutions being tried today, I see a strong incentive for administrators to begin making discretionary moderation choices based on hosting economics and not community will. For example, in a server paid for by voluntary donations from users, the Administrator will be much less likely to penalize a large donor for bad behavior. Another possible incentive misalignment between users and administration is the need to protect hosting cost covering by limiting ease of export. As an instance grows in size and experiences more financial pressure, and if the administrators haven’t planned for sustainability, it will begin to run into additional unexpected costs at an increasing rate.
At the core, what administrators are attempting to do is impose cost on unwanted activities while not disincentivizing wanted activities. Time and effort required to register an account is an example cost, and driving it up would presumably hurt user growth but make it harder for potential problem users to register. What most users want is to be able to express preferences about their desired social experience and then have them met by the rules and norms of their particular instance(s). What the problem users typically want is to know their messages have been seen and to get reactions from the people they target. Essentially, as a macro community, we’re all looking for solutions that impose a disproportional cost on problem users while leaving regular users and administrators as unaffected as possible.
Enter capitalism.party
One potential solution to both of the above problems is to impose a direct and disproportionate monetary cost on problem users, which helps make growth of your instance work for the community instead of against it. One way to impose this cost is to require a token payment on instance registration. While the one time registration fee doesn't cleanly map the lifetime hosting costs to individual use, this method lets the administrators plan finances more sustainably and will hopefully help control problem users.
As an experiment I’ve set up https://capitalism.party as a robust mastodon instance with a $5 registration fee. I’m planning to maintain this instance indefinitely and will keep it up to date and federated with the global network.
I am online there @sharktopus@capitalism.party. Please don’t hesitate to share feedback/insults/concerns for my sanity/appreciation from anywhere that can send messages!
P.S. I’m leaving an open invitation here for mastodon instance admins of any size to reach out to me for technical or administrative support. I’ve been doing ops for quite some time and am happy to help with any and all issues you might run into or be worried about!
Sources / Links
AWS S3 Pricing — Cloudfront Pricing — Pricing worksheet — capitalism.party
