Vicinus

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…

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.

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).

Yeah. I saw the dead website earlier today and have been trying to figure out how to keep the posts working.

The fediverse software post, I could rewrite some code to gather fedidb daily (to my knowledge, they don’t have all time series data available), but their MAU math is suspect. So, not a great option, but my only other thought is basically remaking fediverse-observer and I do not have a server or potentially relevant server skill set beyond cron jobs.

For the threadiverse instances post, I can keep gathering data from the instances I already have in my database, but don’t really have another way to find new ones. Maybe, I could see if I could scrape it from fedidb (I couldn’t get their API working in the past).

In conclusion, the posts are not in a good place :(

You might be interested in the Pylova Piefed fork. It’s from the contributor that this post about Rimu deleting the other side of the story is from (Quokka).

I haven’t had many interactions with either of them (Rimu and Quokka), but if I had guess which is the problematic one in a situation is, I’d guess Rimu.

That’s strange behavior.

Are all the other “views” working correctly (local, subscribed, all)?