I have been known to be a little hyperbolic myself - it does get in the way of clarity, unfortunately. The social media style of communication lends itself more readily towards “slamming” one’s “opponent”, as opposed to calm rational dialogue to arrive at a truth.

“it being forced on all users” and it being “HARD-CODED” are one and the same thing, that’s what hard-coding means.

Hard-coding is the least transparent, least friendly, least documented, and least simple-to-understand form of putting something into computer program code. If instead there had been a variable like if(yes_filter_toxic_mode) then (implement these policies) then people would not be upset anywhere remotely close to the same degree, as when that feature is unable to be turned off (readily) due to its having been hard-coded.

Edit: the accuracy of the OP has now been called into question - apparently this issue is NOT hard-coded after all (reportedly, though I have not confirmed this directly myself). People can still be upset that a “toxicity” filter exists, and how it was implemented, but the fact that it is not shadow-filtering without the express consent of the instance admin makes this a much different discussion than if that filter was forced (via hard-coding) upon people unawares. Consent makes all the difference in the world!!! (The jury is still out whether this rose to the level of “informed consent”, but at least that is a documentation issue, not like the dev acting with nefarious intentions as people have been claiming.)

The facts truly do matter here, and it seems that unless someone is willing to do a deep dive into the code, everything said about this issue is pure speculation. Which so far I’ve only seen one person willing to do, which yielded this (from link I mentioned above):

from src/lib/policies/system.ts:

export async function updateSystemFilterPolicy() {  
    if (SBDisabled && get(userSettings).enableToxicMode) {  
        SYSTEM_POLICY.set(BLANK_SYSTEM_FILTER_POLICY)  
        return  
    }  
   // auto-update of blocklist continues below  

I happen to disagree - they are not the same thing at all, especially given the time differential. It’s a good thing I never said that they were.

There are similarities though. See if you can spot them. Hint: their both having been HARD-CODED is one of them…

What instance’s content would you like to access from Tesseract?

When asked about this HARD-CODED feature that was barely announced when it was slipped into the code, the authors’ response was:

If you dont like it, fork it. Stop bothering us about it, we will never fully remove the slur filter.

- source

Oh wait… my bad, that was Nutomic, speaking about Lemmy. Tbf, after a huge outcry, they did later relent.

I guess software having ideology injected right into it is par for the course these days. It takes an ENORMOUS amount of effort to find any workable solutions otherwise. Compromise is an art, and all the purity testing among leftists works against it (which btw is why conservatism and fascism is winning across the globe right now, at least initially, bc they are willing to set aside their differences in order to achieve a common objective).

Fwiw I would suggest removing this particular feature from a front-end UI alternative and leave such matters to the back-end. Being able to personally block instances is superb, and offering a visual guide to which ones that someone might want to block would also be great, but hard-coding a dedicated list is ineffective at best, especially when the instance admins simply remove it from the code as they run the software without it.

You may also want to cross-post this to !strange_activity_investigations@piefed.zip.