Skip to content

Instantly share code, notes, and snippets.

@ElanHasson
Last active October 31, 2023 14:54
Show Gist options
  • Save ElanHasson/f2212425a459964a1210bda50806236d to your computer and use it in GitHub Desktop.
Save ElanHasson/f2212425a459964a1210bda50806236d to your computer and use it in GitHub Desktop.
Fediverse Moderation Tools Proposal

2023-10-25: The name FediMod and all assets have been transfered to @thisismissem and this document's title and references to FediMod have been replaced with The System .

NOTE: below is the first draft, I'm working to incorporate feedback into it from various folks. Below is a summary of the feedback

To be clear:

Everything would be opt-in by default and admins and mods can choose which other admins or mods see what they're sharing. Think Circles in Google+, as some things they may want to share with one group and other things with another group. They may even choose to share 100% publicly with anyone verified mod or admin.

There would be no centralized authority here-- everything would be run over ActivityPub.

I want whatever this ends up as to be to be ethical, designed and built with empathy and equity in mind.

As much as I'd like to make the tool abuse proof, that is a very difficult thing to do without centralization or some sort of required consensus across nodes (no, i am not necessarily using blockchain for this). Or at least I haven't figured out how yet.

I want the tooling to not do accidental harm quickly ("friction").

I truly believe if we can get some mod automation it'd help a lot of folks by helping to maintaining safe spaces while taking some stress of busy mods.

A great desired end state would be if a new admin can bring an instance online, plugin to the platform and say "do what these instances that align with my values and my server rules do" it could be really help and provide a set of guardrails until they're comfortable making their own judgement calls / form their own opinions on some things.

Some raw notes from the feedback:

Refined some Problem statements the system is looking to solve:

  • As an admin, it's difficult to keep track of the multiple admin chats and fediblock, in order to keep up to date with instances I need to block
  • I would like to have a tool where I can choose to share blocks, reasons, and receipts with a group of admins I have vetted
  • I would like to provide an onboarding mechanism for new admins to get both the history and context for blocks, so they aren't left in the wind

The platform is an administrative tool to help Fediverse instance moderators and admins have a suite of tooling that exists outside of their instance's software.

I've seen multiple instances of individuals creating block lists and sharing them far and wide, with no process in place to appeal nor have much evidence to back up the reason for defederating instances.

This model does not work at all. New instances take up these lists and block others because someone on the internet told them they saw bad things.

It should be up to individual instance admins to determine how they choose to manage their instances, not some random individual or group.

I am proposing a different model. One where a block list isn't prescribed and managed by a single person or small group. A system where individual instances can easily pick and choose based on reports from other instance mods and admins they know and trust.

As the Fediverse grows, moderation will become more laborious. Each instance will end up moderating the same federated content and making the same or similar decisions over and over again. Instead, instance owners should be working together.

A major theme of the platform is to allow for the sharing of the growing moderation burden across all instances using the system.

This would take the form of instance mods and owners adding metadata and context to some or all of their moderation decisions at the IP, email domain, user, hashtag, link, post, and instance levels and to share this information with all or a limited set of other instances that they choose.

Each instance would be able to choose instances where their mod-data goes to. Those receiving instances would have to first approve accepting data from those instances. Receivers of mod data would then be able to make an independent decision, based on the rules of their instance on what action, if any should be taken.

One way to think of the system is sharing abuse intelligence, much like the real-time block lists used for email and other types of network abuses, but unlike those block lists, admins don't have much control over which blocks they implement.

In the Fediverse, many admins know each other and have built relationships. The Platform will also allow the configurations of rules. If there is an instance with whom an instances trusts, they can configure a rule to automatically apply the same moderation decisions that instance published to the Platform's network. This type of rule is great as admins and moderators aren't always online, or are dealing with other matters. These auto-applied rules could then be surfaced into a Review Queue where a human can review the decision at a later date and decide to roll it back.

Of course, like everything else, the types of data shared with other instances and with whom it is shared with should be up to the instance admins.

User Transparency

In the Fediverse, there is a culture of transparency with users, which is important as transparency builds trust. It is our position that the instance admins be in control of what is shared; much like the instance block list.

Admins will be able to share the supporting information which led to their decision, whether it be screen shot evidence or just plain text. Any information that came from other mods would be anonymized if it is shared directly with users. Of course, bad actors could deanonymize it if they wanted to, but that risk already exists today with existing models.

Other Features

The Platform isn't just about moderation, it's also about making life easier for admins and moderators.

Hash Tags

Hash Tag seeding along with Hash Tag accessibility aim to bring a better experience to users both new and experienced of the Fediverse.

Hash Tag Accessibility

There is an issue in the Fediverse around hashtags not always being accessible to folks who use screen readers. Today, a Mastodon instance defaults to the display of a hashtag using the same casing used the first time the instance observed it. This makes the Fediverse less accessible.

The Platform will have a system that will be able to take hashtags that aren't accessible and make them accessible by properly casing them.

For example, #thursdaythrowbacks would be re-cased as #ThursdayThrowbacks and would be displayed that way in trends and the auto-suggest functionality.

Since an instance only knows about a tag the first time it observes it in a post, many instances do not have all of the tags.

Once properly cased, these accessible hashtags would be federated to other instances, where the admins would have the ability to accept, reject, or propose a change. Changes that are proposed would then be pushed out to other admins so they may make their own decision as well.

Hash Tag Seeding

When a new instance joins the network, there are no hash tags in the local instance's database. The admin of that new instance can request their local instance be populated with tags from other instances that have been a part of the Fediverse longer and therefore have a large hashtag library.

@ElanHasson
Copy link
Author

I'm looking for feedback on the above. Thanks!

@supernovae
Copy link

Instance block lists and methods to make that easier/more known would be great. I think we're on the cusp of that.

Hygiene for Hashtags is very much Needed. Adding CamelCase for screen readers is icing on the cake.

I think step 0 should be "filter lists"

I should be able to have a dictionary of things I never want to see trend, registered as (users) or show up in posts/news (bad URLs)

@ElanHasson
Copy link
Author

What is a "filter list"? Are you saying racial-slur-here should never be able to trend even if your instance has never seen it? If so, that is the Hash Tag Seeding I described above. 🚩I will make that clearer.

@supernovae
Copy link

Yes, whatever "bad thing here" should be able to block:

*hashtags
*URLs
*usernames

It's whack-a-mole with hashtags and usernames and I'm seeing some spamming of URLs that would be nice to block that contain slurs too and if they do it fast enough on across enough instanes, they tend to trend as news/posts.. (barf)

and maybe even apply to an automoderator that flags posts containing those words (this is complicated in many ways on privacy front)

@ElanHasson
Copy link
Author

ElanHasson commented Jan 10, 2023

🚩Username is a good one!
Can have the webhook for account.created hit your FediMod instance to validate against your rules and take action, such as suspend, delete, can probably even have it produce a report from the FediMod user on your instance (this would be the user associated with the API token FediMod would have), and then FediMod can observe the created report and act from there, leaving you a paper trail AND letting the user know.

@johnclint
Copy link

I like everything I understand in the proposal. (My geek cred is minimal.) I'm especially happy that the FediMod toolset will be outside the Mastodon admin interface. My small instance is hosted by toot.io, so I don't have access to all the controls available to a self-host instance. For example, I can't run Ubuntu commands. So, I hope I will be able to activate and use FediMod without going through my host.

@ElanHasson
Copy link
Author

The current plan and line of thinking is for FediMod to contribute to the mastodon code base to add additional webhooks and apis to be notified of certain activities.

The apis will help the ecosystem as a whole. Everything you can do from the command line IMO should eventually end up as an API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment