cross-posted from: https://lemmy.dbzer0.com/post/72685299
I discovered this after upgrading our instance yesterday, which also upgraded all frontends to their latest versions as well. After I did, our Tesseract frontend stopped working and I noticed immediately as it’s been my primary for a while. Initially I thought it was an API version mismatch, but no, it was much worse.
Someone pointed out that the developer of the frontend added an explicit hidden and unmodifiably blacklist which includes any and all instances to the left of Kissinger. There’s a commit which also explains their specious reasoning about our instance specifically, as it seems we’ve been on their shit list for a bit longer than that.
This instance and its admin staff encourages identity politics, groupthink, mob mentality, and extremist solutions to societal problems. Users who advocate violence are not moderated so long as the admins agree with the target. Caution and critical thinking are advised when interacting with this instance or its users.
When you use tesseract to connect to one blacklisted such instance , you just get a message informing you that Tesseract is “incompatible with that instance” which leads one to think of a technical issue, like an API mismatch, rather than the dev being an opinionated coward.
Isn’t it funny how all the software developed by turbolibs, like Piefed and Tesseract, end up with hidden control mechanisms from developers who think they know better than everyone else? That they don’t just think they deserve to tell you what you should think, but they should manipulate you to think it? Isn’t it funny how libs go on about how bad it is to support lemmy due to the ideology of the devs behind it, and yet lemmy has 0 opinions as a software? It does make one think…
Anyway, I forked - it as one does - and disabled the blacklist, but since this is a massively ideologically compromised software, I’ll doubt I’ll keep this frontend up after Lemmy 1.0. I think we’ll bring up mlmym again now that someone’s maintaining it again.
But OpenStars! You’re commenting using the HARD-CODED frontend that talks to the HARD-CODED backend!!!
How disingenuous can you be?? People are clearly upset about the combination of it being a personal blocklist/vendetta/whatever and it being forced on all users, not solely the fact that omg it’s HARD-CODED. While some people may have disagreed with the slur filter it didn’t ultimately prevent interaction, enabled or not; unlike this.
“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):
export async function updateSystemFilterPolicy() { if (SBDisabled && get(userSettings).enableToxicMode) { SYSTEM_POLICY.set(BLANK_SYSTEM_FILTER_POLICY) return } // auto-update of blocklist continues belowThat’s what I was saying after I was being a little hyperbolic, I used a definition and your exaggerated capitalization of hard-coded interchangeably