I’ve been favoring Mastodon over Twitter awhile now and have been following the moderation drama. A solution occurred to me.


Mastodon is a decentralized version of Twitter. It allows anyone to create their own instance (such as mastodon.social or appdot.net) and run it as they please. Think of an instance as your own private Twitter server. Instances can be (and often are) “federated” in what is called the Fediverse. A user on one instance can follow and interact with any user on any other instance within the Fediverse. Or not. A user could also choose only to view their “local” timeline, which shows only the activity on their own instance or the Federated timeline, which shows activity from all federated Mastodon instances.

This gives users a lot of control over what they want to see, but not as much as it could. This fact has given rise to a debate over free speech and has resulted in a rather public fight over whether undesirable instances should be blocked. The more specific technological issue of how to block, say, an extremist instance is proving to be difficult as well. App developers have blocked specific instances known to promote hate speech and violence, but this has earned them “review bombing” (droves of negative reviews by angry mobs; in this case, proponents of hate speech and violence).

Moreover, Mastodon’s creator retains control over his open source creation and has resisted adding much-needed moderation features. This puts the burden of filtering poor-quality (and outright hostile) federated instances on the users.

So how can we address this? If it’s on the users to moderate, I propose we “own it”.

Possible Solution

Mastodon is built on ActivityPub. Looking at the ActivityPub documentation, there seems to be top-level built-in support for Likes and Dislikes being two separate things (as well as Undo actions for a dis/like, which makes “taking a like back” is separate from “disliking” something). That means the protocol underlying the Fediverse could support a StackExchange-like voting and tagging system for a service to rate domains/services in the Fediverse.

Imagine a scoring system Mastodon clients could use to auto-filter low-quality/specific-tagged origins. What I envision is a rating system that lets established accounts (like those with a minimum karma and public identification) up/down-vote a service, or tag a service with a topic (“General”, “Techies”, “Artists”) or label (“Bigotry”), and vote on those tags (which would help avoid unfair labels being attached to a service), showing the tags only if they reach some threshold. The tags would be curated by users with moderator-level karma, which itself can be based in part on the “accuracy” (agreeing votes) of your tagging activities.

It may even be beneficial to add a time window to the scoring system, so that only the past-so-many-months are considered. This can both eliminate bad actors (spam accounts to affect vote) as well as give a Fediverse member a chance to clean up its act and recover.

Meanwhile, client apps can simply support polling (and contributing to) the rating system, rather than sticking their necks out and getting rating-spammed by angry bigots ranting about “muh freedomz!” by maintaining a list of singled-out instances. The system is then opt-in and the data maintained by the community. This also means we don’t have to rely on – ahem – a stubborn code owner to adopt the standard within Mastodon itself.

Overall, if it’s thought out well and takes an effort to become a trusted contributor to the system (and the score is maintained by “most recent activity”), it should empower users to engage their own filters so the Fediverse can Fediverse and the client apps can simply ignore toots from low quality / filtered sources.

Client app developers could offer their users the ability to filter toots from instances with low scores and/or undesirable tags (like “Nazi”) with sufficient votes from the community to justify the tag is valid. The app would ideally ask the service about toots from any instances it sees and whitelist or blacklist them based on the user’s preferences, displaying only toots from whitelisted instances. Every so often (once a week?), a given instance is polled again using the service and either reaffirmed in its position or updated (eg, whitelisted if it cleaned up its act or blacklisted if it recently earned enough bad karma to meet the user’s criteria for blacklisting).

Win/win. Now can someone build this, please? Then can Mastodon client apps implement it? Please?

Related Posts