Self-explanatory title, but for someone bootstrapping (if it is even a right word) from other instances’ blocklist this could be very useful.
2 Likes
One problem I personally have with importing blocklists like this, is that they can easily become a vector for abuse.
In 2018 or so, I’ve seen harassers target certain instances by slandering them on the fediblock hashtag. Several people blocked those instances without even requiring proof or checking things out. Later, the fact that “many instances” are blocking these, was considered enough proof to block them (“why would they be on so many blocklists if they aren’t bad”). Even until today I sometimes see new blocklists pop up where some of these instances are listed.
There’s other, non-fedi, examples of blocklists being abused to silence certain people over personal politics or simply personal fueds.
Obviously people need to be able to block (and otherwise moderate what comes in from) remote instances, and I understand wanting to bootstrap from an instance that’s moderation-wise close to you. But if the work really becomes too much, I hope we can find better ways than blindly copying other peoples blocklists. Although I am not sure what that solution would look like.
1 Like
I think the easiest answer here is “there’s no need for the core system to support this, it’s something that could be pretty easily achieved via a script that calls already-existing APIs”
2 Likes
While I do agree with you in principle, the docs are not easily digestible and this is not a trivial task to ask a lay person end user. I just tried it, with proper auth, and I get a 400 “Bad Request” response with no indication of what went wrong. I was trying to send a POST request via Firefox dev tools FYI.
Perhaps if there is someone inclined to write a quick how-to on this, it would be super helpful for the rest of us.
PS: I do agree regarding the comment about blocklists being a vector for abuse, but I don’t think that is a valid response to a request for easier admin tools. Current workflow on the MRF admin page is a bit subpar, IMO.
I wholeheartedly despise the practice of a large number of instance blindly following what a few vocal individuals do with their blocklists. However, having migrated server quite a few times between hosts etc, the ability to import in bulk even the ones I had exported (which would also be needed IMO), would be useful.
Oh wait, this could be imported via config if entered there, and migrating to DB right. I guess an exported config from DB would also contain the list?
exported config would allow it
the only compromise i might be able to offer is a CLI task to do something similar, it would depend on configDB being turned on, but it could work
I think support for Fediseer would be nice: https://fediseer.com/
It’s much more flexible than static blocklists and allows both block and allow-lists.
may i ask what the point would be for explicit support for this one API that may or may not exist in a month, day, year?
what exactly do you see it doing?
It’s fully open-source and you can also use it to run your own endorse-chain allow-list or automated blocklist system.
Definitely better than importing some outdated .csv block-list.
It’s a pretty new system (originally developed for Lemmy), so it isn’t entirely clear where this will go, but I think out of the box support in Akkoma would be neat and an extension of the bubble idea.
This kinda reminds me of an idea that came up in the past; FOAF (Friend Of A Friend), which also works with trusting other instances. The idea there is maybe somewhat similar, but without centralised service.
- You have a list of “friends” (could be bubble TL, could be a separate list). These are people you both endorse and trust
- When a new instance pops up, they get put on a waiting queue
- When they are trusted (ie considered a friend) by a friend, you trust them to be ok, and automatically allow federation. (note that “trusted” and “allowed” are two different things)
- When they are not trusted by a friend, federation does not go through
- An admin/mod can check the queue and decide to allow, or deny said instance. Or even immediately mark the as “friend” (the latter meaning that the instance in question is now both allowed, and also trusted).
Functionally it’s an extension of a federation queu, who is an extension of allowlist federation.
But I’m unsure if this would really be a good solution. There’s many instances, so I fear a federation queue will quickly overwhelm mods. And the FOAF element can automatically allow some instances, but maybe not enough to really make a difference.
But maybe some tweaks to this idea could make it more usable?
I do kinda miss the specific problems people are currently facing. Do people get unhandleable ammounts of spam messages? If so, what kind? We already have an MRF to drop messages when it’s the first time an account posts and it has a link in it for example. This should already help against that class of spam. There’s also Keyword policy to automatically moderate based on content of posts. Maybe it makes more sense to extend some of those, instead of building complicated systems? But then it’s important to know what specific problems people are facing.
Fediseer as a project was started because some bot script started creating literally hundreds of thousands accounts on random Lemmy instances and people were afraid they would start spamming (they didn’t so far and most got removed again, so the motivation of creating these is unclear).
But in the end it is an idea similar to yours. There are a lot of people that would rather have allow-list federation (or try to add a lot of entries from external sources like the bad space), and this project tries to strike a balance between these wishes and keeping a more open-federation that still makes it relatively easy to open a new instance and start federating (and also gives those new instances a jumpstart for their blocklist which they will need sooner or later anyways).