Do you SERIOUSLY think a corrupt republic where the elite is actively controlling the narrative (and thus demonstrates their understanding of its importance); is not going to see Mastodon as a threat?
This is THE biggest non centralized non controlled non capitalist platform in the US and maybe the world
Mastodon is a THREAT to capitalism and fascism JUST BY EXISTING
Instead of using an #intransparent#blocklist that is maintained by people more unwilling than unable to accept valid criticism and reflect upon it, consider choosing one that is #tranpsarent and that is actively maintained by people that #DoBetter!
One of the things about scoring algorithms is that they are prone to bias from a lot of sources you don't think about unless you actually work in this space.
For example, with blocklists, let's say you have five trusted sources and you use a majority evaluation.
You also don't get a pass, incidentally, by pushing a decision tree to the user. That just says "oh it is your fault for choosing the wrong list."
Make your choices. If you vary your assumptions that's one thing, but call that out explicitly ( @Seirdy does this, for an example).
If you acknowledge that then you start down a path of making conscious choices here and that's far far better and far more responsible as a way to build a scoring algorithm (or a #blocklist).
Last night, after a tip-off, I decided to start checking out the instances federated with BSD Cafe. I came across some truly appalling instances, featuring horrible images and content that could end up on our timeline. As a result, I've begun integrating some blocklists into BSD Cafe, taking a gradual approach to avoid going overboard with the blocks.
This has led to the immediate removal of over 10 followers from my profile—potentially good folks, but from highly questionable instances. I can't stand by as BSD Cafe gets tainted with such materials.
Friends of the Fediverse, choose your instances wisely. It will ensure a far better experience for everyone.
If one gets deeply invested in defending a specific person, one limits one's ability to see or hear anything problematic about that person.
Totally unrelated: Wondering what the #blocklist discussion would look like if I filtered out all mentions of a specific name?
As a server admin, what are the things you would like to know before applying a domain block (and/or a #blocklist), or what kinds of steps would you like to perform?
Some of my thoughts:
How many people would be impacted on our server and theirs?
How significant the impact would be for those impacted?
@Are0h And you provide a good case study of ignorance and unprofessional communication.
I'm still waiting for your comment since overwhelming evidence shows that you weaponize #TheBadSpace for personal vendettas - which discredits said #blocklist...
Y'all are going to get me to actually write a #blocklist tool at this rate, even though I know it won't help, just so I can put a pin in these discussions -.-
When it comes to #blocklists we should probably at some point talk about soft pressure, conflicts of interest, and why/how "$Foo didn't make the decision [directly]" doesn't mean that $Foo did not, in fact, have a role to play in the decision.
If I want to truly claim third party independence in my hypothetical #blocklist, it means something significantly more than "I am not directly making decisions for the blocklist."
Like… I've seen now a few different groups make claims along the lines of "I don't control what's in the #blocklist that I run"
First, this is a nonsense claim for a variety of reasons. You made a series of decisions that configured it
Second, if you are friends or allies with anyone who is making decisions on your behalf—even if you don't know about it—that undermines your ability to claim independence
Finally, even to the degree it is true, you should expect skepticism and be transparent
One more #blocklist thought for today (welcome to the blocklist channel!)
It's dangerous to promote a blocklist for a purpose you aren't validating it for.
Put another way:
If your anti-spam blocklist isn't validated for targeting spam instances you have a problem. If it is just generically taking a list of instances from various sources regardless of block reason that's a significant problem
You can say "this is just a blocklist of instances blocked by others" if that's all you are doing
I do not accept the logic of "it appears in <#blocklist $foo> therefore it is a bad instance."
That to me reverses the question: It is treating the blocklist as determinative.
Rather the question should be reversed: an instance is added to the blocklist $foo because someone has made a determination that it is a bad instance for some documented value of bad.
But I'm seeing a lot of "it is in the list, therefore it is presumptive that they did something wrong."
Because it goes to the heart of one of the core failure modes of consensus-based #blocklists.
If services A-E coordinate on a #blocklist and import their own blocklist because the blocklist is determinative then they will propagate the decisions regardless of accuracy. There's nothing to stop bad reports because the decisionmakers are relying on the output to make a determination and then feeding that back into the system.