As the Fediverse grows, the amount and frequency of harmful spam also increases. The feudalistic structure of the network creates notable moderation overhead as every instance admin has to ban offending remote accounts and remove their content themselves, if the originating instance does not act quick enough or such delete actions are not federated properly.
An example (and my motivation for this post) are reports from the last days about accounts which post CSAM content. This is especially problematic, as media content gets duplicated to every receiving instance.

The following idea came to my mind: A software which sits on top of Activity Pub and creates a kind of court. Instances of this software are independent courts. All users can elect admins / mods of their home instance as judge. Everyone can post a case via normal Fedi posts to the court and the elected judges give a verdict via majority vote (votes are also normal Fedi comments with special formatted content). Once a case has a verdict, all instances should immediately apply the decided action against the offending content / account. This can be done via a bot which is set as an instance moderator and follows the published verdicts of a court instance the local admin trusts.

This way swift action can be applied through all instances which follow the court at once. By having periodic elections it is kept democratic.

And the task of the court is to defend universal rules all following instances agree on. Not to handle politics between instances.


What are you thoughts on this matter? Or do other approaches to solve this issue already exist?


Update:
From this came the idea that instances can follow mod actions of other instances and apply them if x% of other instances did the same.

I think this is an interesting approach which might be better than my proposal. So I would like to hear your thoughts about this too.

you are viewing a single comment's thread
view the rest of the comments
[–] 8 points 1 day ago (6 children)

I think Pylova (a soft-fork of Piefed) is at the forefront of moderation tools in the threadiverse.

I think their recent addition of shareable user-subscribable block-lists is a good direction to go. I think this can be expanded to instance-level subscribable block-lists. There could be a variety of lists (CSAM, scrappers, scammers, agentics, etc.) and each instance chooses what list(s) to subscribe to or build their own for others to subscribe and contribute to. The lists would be easily fork-able so that any instance can take control of their own moderation, if they disagreed with an addition/subtraction to a list.

For some lists (like scrappers), I think automatic addition could be set up to quickly "inoculate" the rest of the threadiverse against them. Perhaps one approach could be any IP that clicks on a non-user clickable link or gets stuck(?) in Anubis could be added.

I think subscribable block-lists for instance admins could be a great way to protect the threadiverse (perhaps expanded to the fediverse as a whole or just any website in general) against any problematic actors quickly and at the first encounter (alternatively: after (x) # or % of instance admins add them to a list).

Apparently some of these lists may already exist in some form (@Christopher@lemmy.grey.fail: "I was able to implement community maintained blocklists."). So, my thought would be to make sure these lists are a standard format (if they aren't already) that instances can auto retrieve and contribute to.

Anyone: let me know if you have any thoughts or see any issues with the idea (constructive criticism only, please).

  • source
  • hideshow 6 child comments
  • [–] 2 points 20 hours ago (1 child)

    Posts hitting the fediverse over the past 24 hours or so are essentially creating a new account for each post. The accounts are across many instances and posts across many communities.

    I'm not sure how this proposal would work in the current environment.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 20 hours ago

    The accounts are across many instances ...

    Good point. If they have a shared identifier (IP or something) than I could see the block list working. If not, and it's probably not, then yeah, I don't think the block list would be able to handle that spam.

    I wonder if there is any approach that could. Different origins, different entrances, and different targets, that's a difficult one. It's not my knowledge base, so maybe something exists that could handle it? I'd be curious to hear about it, probably pretty cool.

    Maybe machine learning on interaction rates (sign in to post timeline)? I'm assuming it's automated though...

  • source
  • parent
  • [–] [S] 2 points 1 day ago (3 children)

    The difference between blocking and purging is that a blocked account is still residing on the instance (even more so for user blocks instead of admin blocks). As the data is still there, it opens possibility for legal trouble. Full purges by instance moderation action is different.

    The scope of my proposal is not to help curate and filtering content for instances, but to enable widespread coordinated action against content which was already created and is harmful without any room for interpretation.

    approach could be any IP

    That is a whole other issue. Scrapers and request spammers, not content spamming accounts, can be combated with already existing technology at the reverse proxy server. There are big crowdsourced IP banlists which are continuously updated.

    I think subscribable block-lists for instance admins

    This would be the easiest solution. But I think it will lead away from individualism of instances, as all decisions are automatically applied, instead of only a manually reviewed subset.
    Your idea with applying the mod action after a threshold of other instances did it too is something to consider. It will keep individualism but also creates "avalanches" once enough instances in the network agreed on a decision, which might be even better for propagating swift action against general harmful content.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 2 points 22 hours ago (1 child)

    They each serve a different purpose - instance bans are "hard" (firm), and appropriate for e.g. CSAM & trolling, whereas shareable blocklists are for more "soft" (personal choice) matters, like whether someone prefers to not see posts from bot accounts that rarely if ever respond to comments within those posts (although arguably a bot account that is not properly registered as such could be grounds for banning, depending on instance rules).

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 19 hours ago

    It's odd equating csam (absolutely terrible) and trolling (something that the definition of is extremely flexible). Hell even establishing bot behavior is difficult if not using the bot tag or account.

    All in all apart from the csam everything you described is dependent on the instance so would not work with a top level

  • source
  • parent
  • [–] 1 point 1 day ago

    Appreciate the feedback :)

    The difference between blocking and purging is that a blocked account is still residing on the instance (even more so for user blocks instead of admin blocks). As the data is still there, it opens possibility for legal trouble. Full purges by instance moderation action is different.

    The scope of my proposal is not to help curate and filtering content for instances, but to enable widespread coordinated action against content which was already created and is harmful without any room for interpretation.

    Makes sense. I suppose my described lists could also be made into purge lists.

    That is a whole other issue. Scrapers and request spammers, not content spamming accounts, can be combated with already existing technology at the reverse proxy server. There are big crowdsourced IP banlists which are continuously updated.

    Not my knowledge base, so good to know that already exists.

    This would be the easiest solution. But I think it will lead away from individualism of instances, as all decisions are automatically applied, instead of only a manually reviewed subset.

    Your idea with applying the mod action after a threshold of other instances did it too is something to consider. It will keep individualism but also creates “avalanches” once enough instances in the network agreed on a decision, which might be even better for propagating swift action against general harmful content.

    Definitely a balance needs to be struck, between quick action and preventing abuse.

  • source
  • parent