Anyone got an API endpoint of the "most blocked instances" handy? I wanna add it to the initialization flow for the #DistributedPress #SocialInbox
Ideally it'd be nice to say "Here's the top 100 most hated instances so you can preemptively block them if you'd like". It's not perfect but I think this would make it easier for small publishers to get started.
Huge thanks for folks/ input on this. We're going to start with the mastodon blocklist format version of gardenfence and go from there.
We'll have a flag for folks to toggle during setup for pulling from a URL and have it set to this one by default:
https://github.com/gardenfence/blocklist/blob/main/gardenfence-mastodon.csv
To be clear though, this will just be on the SocialInbox server to preemtively filter out replies and follow requests from such instances.
Sadly we need a whole new approach to figure out how to prevent instances like this from reading your posts since all your data is available via ActivityPub and HTML on the #dweb. 😅
@mauve not exactly what you're asking for but maybe #TheBadSpace works for you?
@j3j5 Yeah defs a fan of this project and into integrating at some point. For the moment I'd like to reduce the overall size of the blocklist and focus on something with a bit less nuance like "the top most blocked instances" since it's easier to grock without nuance IMO.
Ideally instance operators would then add / remove more allowed/blocked instances from there.
@mauve In case you missed it, this seems like an interesting update that may better fit your goals for using #TheBadSpace
@j3j5 very much so 🥰 We'll be doing some more work on our moderation system in thr next quarter so it'll be useful to see where we can align
@mauve right, while I agree it would be useful, this kind of thing doesn't exist for a few reasons. one, as you found, bad instances like to track who have blocked them, either as a kind of high score or for retaliation. two, collecting such statistics would require instances to disclose their block lists in a machine-readable format, which plenty do not do and are not willing to do.
@mauve probably better to just support importing a blocklist in the mastodon format for now
You can then do what I'm doing in a Mastodon PR where we offer to pull in via a URL, offering several common lists to choose from
@thisismissem Yeah good point. Any benefits to mastodon's format instead of the fediblocksync format? I assume the mastodon one is more widely deployed at this point?
@mauve yeah, that and most blocklists I know are deployed in that format; though there is a bunch of interest in moving towards a standard format, not purely adopting Mastodon as standard.
@mauve like, fediblocksync but with the ability to obscure the really harmful URLs would be wise, but it's kinda a future piece of work
@thisismissem Dang yeah having all these domains in a list seems like a great way for folks seeking out communities like that to find each other 🥶 Ah well, we'll adopt whatever new thing comes along once we get to it!
@thisismissem @mauve Would hashing the URLs of instances, publishing the hashes, and then when a server wants to federate hashing its name, checking it against the list, and blocking accordingly be a solution here? Similar strategy to how haveIbeenpwned handles things I think...
@hank Yup! I think as @thisismissem alluded to the only challenge is getting folks to actually adopt such a strategy. :P
@mauve you can't prevent read unless content isn't publicly available
@thisismissem Yeah! Exactly. At the very least the inbox level block will help reduce how much your posts get pushed to those instances and their global timelines.
@mauve I'd recommend starting with @Seirdy's FediNuke worst-of-the-worst list. https://seirdy.one/posts/2023/05/02/fediverse-blocklists/
I came across one a while ago but it seems to be run by some folks that I don't think I could trust or even mention in any professional contexts. :/
I was kinda hoping #FediDB would be tracking something like this but I didn't see anything in their api