Skip to main content


Add this to the pile of ideas I'm unlikely to ever make, not because it's super hard but just because I'm so constantly exhausted and out of spoons... steal away if you want to make it:

There's basically the "big server" problem on the fediverse, where a super large open registration server has so many people on it you don't want to block it and lose all those people... but it inherently is less effectively moderated. Or even on smaller instances there's so many cases of "this wouldn't be acceptable on my instance, but isn't bad enough to defederate a whole instance over".

It's manageable, but has limitations that get worse as the network grows. It's even one of the concerns people have with bridges and corporate platforms adding support (ie. bluesky and threads respectively).

But there's an idea in Bluesky I kinda like that feels like it could be tweaked and imported over here. Which is subscribable moderation.

I'm not proposing just subscribing to all sorts of block lists from strangers, but a way of having shared moderation that people can team up on.

Basic idea I had was an open source platform (so others can run it for both redundancy and cutting down on smaller censorship disputes). On that platform, someone can create and become the admin of a moderation group. Then they can invite other people to that group as moderators (or in the case of private groups, members).

Then basically have auditable moderation lists made by the groups (showing which moderator took which action and when... especially good for undoing things if problems arise, but also for checking the list before you import an update), then server admins and users can follow a list and subscribe/import it.

Was even thinking this could be improved with things like public reporting, where reporting it to the server would send the report to all lists that haven't already blocked them (servers could even share this between eachother easily enough). Additionally admins could piggyback their list off of others (basically lists that are less restrictive than yours, so you might pull from "We only block Nazis" because you know anyone they're blocking isn't going to be in question).

#FediMeta #Meta #Ideas #Idea #Suggestion #Suggestions #Moderation

Shannon Prickett reshared this.

in reply to Shiri Bailem

Yea I have a prototype of this built. The annoying thing is unsubscribing from blocklists means undoing blocks and those don't always federate cleanly.
in reply to Shiri Bailem

Yea, part of the AP protocol is you have to tell the server of the user you are blocking. When you unblock you have to also tell the server as well. If those messages are not processed correctly the block isn't lifted.

Now normally, you'd just manually block and unblock again to send a fresh message. But when you are dealing with lists there are UX challenges there. How do you communicate to the user that a block/unblock didn't go through and they need to retry? Or do you just keep retrying with exponential backoff? None of this is insurmountable, but distributed networks are hard 😅

in reply to ראַף 🟣

Oh and there is some disagreement over what a standards-compliant server should do about Block messages

socialhub.activitypub.rocks/t/…

in reply to ראַף 🟣

@ראַף 🟣 I honestly wasn't imagining integrating with the protocol itself at all, I was just picturing it exporting an importable block list and leaving it to the platforms to support importing it, or other tools to handle importing and applying it.
in reply to Shiri Bailem

Well right now at least on GTS and Mastodon you can import block and mute lists. But it's a one-off. There isn't what I think we both want which is a subscription to a block list where we can periodically diff against and undo/redo blocks and mutes.
in reply to ראַף 🟣

@ראַף 🟣 I definitely agree that there isn't an explicit subscription option, and that's entirely down to toolkits on the instance side imo.

I imagined manual imports, but with convenient links for those who might want to build tools to automate those imports. Maybe an option to also email updates as a way to notify, but that's kinda secondary imo.

I just pictured along the lines of:
example.com/modlists/Punch-All… for raw importable blocklist
example.com/modlists/Punch-All… for a simple history that shows the blocklist stuff, plus add/remove, who, and when.

Then others can build tools to handle much of it, (like on friendica it would take barely any effort to write such a tool for server admins).

And basically just take unix methodology for the tools that import into other instances, focus on providing the list and a separate tool can be used to automate it.