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.
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.
The Platform isn't just about moderation, it's also about making life easier for admins and moderators.
Hash Tag seeding along with Hash Tag accessibility aim to bring a better experience to users both new and experienced of the Fediverse.
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.
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.
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.