Pros and Cons of a Small Mastodon Instance

Mastodon and its Fediverse alternatives^[1] have been all the rage since the major loss of user trust (the breaching of a “trust thermocline”^[2] if you will) brought on by a change in ownership in a previously dominant centralized competitor (Twitter). Today, we join the universe of fractalized, contradictory voices arguing about how to do Mastodon the Right Way™. Specifically, we consider the question of what instance you should join, and specifically, whether you should join a large, general-interest instance, or a more niche one.

A lot of these thoughts pertain to the general question of how to choose a server; see the Fedi.Tips page about this.

Pros and cons

Local timeline

One of the main reasons to be particular about choosing an instance is to get a local timeline that is more relevant to your interests. Try looking at the local timeline of any large general-interest instance, like the one for mastodon.social, and you’ll see a firehose of every post that every user on the instance makes. The problem is that this ends up being a stream of mostly irrelevant information, as most posts won’t be interesting to you, effectively rendering this feature useless.

On the other hand, try finding an instance on JoinMastodon.org’s server list and looking at its local timeline (for example, mastodon.gamedev.place or bookstodon.com). While there will still be general personal posts, there will be a lot more posts about the instance’s topic.

Mastodon has an emphasis on having individual users curate what they see over algorithmic curation of content. This is one of the many ways this is done. On the other hand, it is possible to ignore the local timeline completely.

Like/boost counts aren’t synced between instances, though I have heard that there is some work to change this. Until then, if a community that’s important to you is on a different instance, you may have a hard time seeing this info.

Vanity handle

The typical format for Mastodon handles is @username@domain, like @[email protected] or @[email protected], with an inherited similarity to Twitter handles. Roughly half of the info on display in your handle is the instance domain name, and is a place where you can signal aspects of your identity or interests to others. A little attention to image is nothing to be ashamed of 😉.

You can use the instance to signal your interests/identity. There would be very little doubt that anyone on equestria.social or pony.social is a fan of My Little Pony, or on mstdn.ca wants to represent Canada as part of their identity.

If your identity and interests are truly eclectic such that you don’t want to be pinned down to a single thing, you may prefer to stick to a general-interest instance. mastodon.social is a special case in that it’s the closest thing to an “official” instance. Or, if brevity is the deciding factor, you can reach for the instance with the shortest domain name you can find like c.im or mas.to.

Ideology

If it matters to you, joining smaller instances prevents one instance from amassing too much control of the network. For example, mastodon.social has arguably reached the position of being unblockable (not technically, but practically) by virtue of being so large. As an instance admin, not being able to talk to accounts on the largest instance would hugely inconvenience your users enough to potentially abandon your instance, so it would be a tough decision if there were a reason you’d need to block mastodon.social. Therefore, it makes sense with a kind of Kantian logic that one should join a smaller instance.

Operator competence

As with any site you use, you place some degree of trust in the operators of the site, that they aren’t malicious (attempting to steal your secrets like passwords and DMs) or incompetent (using insecure configurations, accidentally deleting all the data, etc.).

Another axis of operations, besides the technical aspect, is moderation.^[3] A lack of moderation on your instance will have various negative consequences for you.

• Bad actors will get up to making harassing posts that no one wants to see but them, with none to stop them.
• This unmoderated state may get your instance defederated, resulting in your account being blocked by proxy.
• Engaged users won’t want to deal with these problems and will migrate to other instances, further concentrating the bad actors.
• Your instance won’t be blocking new instances that pop up with bad moderation, resulting in more trash coming your way.

Where instance size comes into the equation is what I’ll call the “scale heuristic”. There is a natural assumption that someone successfully operating a large Mastodon instance without any visible dumpster fires is competent, because a sufficient size would inevitably bring such problems to light. “Reputable” does often mean “familiar”. This being an assumption, there is nothing stopping a large instance from trudging on with just-good-enough-not-to-get-defederated moderation, or a small instance to be relatively free of problems.

Evaluating instances

If you’re considering joining an instance that isn’t a commonly recognized/reputable one, there is some due-diligence you can do.

Statistics

I unfortunately don’t know of a tool to easily check how trustworthy and well-maintained a Mastodon instance is (and I sense an opportunity for number-crunching aficionados). For large instances, my understanding is that every instance on joinmastodon.org meets a certain quality bar. demo.fedilist.com, although it’s still in development at the time of this writing, is useful, and you can manually perform the following checks.

• Registrations open, unless you have some way to register otherwise.
• A recent version is running, under the assumption that attentive staff are quick to update.
• Monthly active users > 50 and posts/user > 40, or whatever threshold of activity suits you.
• Running a fork of Mastodon or a less popular Mastodon alternative may be a positive or negative signal depending on your priorities. A fork suggests the operator has a certain savvy and is willing to navigate the differences involved in non-standard software. On the other hand, there is more potential for things to go wrong.

About/rules

There are also the information the instance itself provides on its /about page. An example of a very well-thought-out about page is the one for mstdn.social.

• Does it have a well-thought-out list of rules? One that is more specific than “just be cool bro”?
• Are you okay with all the rules? For example, some instances may not allow NSFW content period, while others will require a content warning, while others won’t require a content warning.
• Does it publish a list of servers it’s defederated from (under the section “Moderated servers”)? Do you find the reasons given to be agreeable?

Owner

The owner will be included under “Administered by:”, or somewhere else in the instance about page. It’s a good idea to check their profile and ensure that they don’t seem too disagreeable.

Conclusion

Hopefully you’ve found this helpful in your search for the right instance. If you make the “wrong” choice of instance, Mastodon has a process to migrate instances^[4], which I haven’t tried myself, but which I see people do all the time. The process allows you to keep all your followers.