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.
@Quokka Wait a moment. Is it the same tesseract that develops the OCR? Because I sometimes use that OCR for NVDA screen reader (non visual desktop access). If so, I’ll take it off immediately! This kind of hardcoded deny list, is an abuse. Worse than the one I noticed 25 years ago on MSN messenger where you couldn’t label yourself as “John Doe - webmaster of [project]” but then if you named yourself “I’m the drill for young asses” (said it less rude than it was), Msn messenger let you place that display name upfront.
Let me say that if you develop a software where you deliberately block pro-trans, pro-sustainability or topic you dev potentially dislike, your software shouldn’t be distributed to the public.
No, different Tesseract!
@Quokka Sorry, and thanks for explanation. It’s a serious situation anyways. This kind of devs shouldn’t be accepted into open source community; maybe I’m too extremist
No you’re absolutely not. Allowing this in a community is tacit agreement with discriminatory attitudes against queer people.
@zqps I’m afraid discrimination has become mainstream. Against queer, against black, against people with disability…
deleted by creator
No, Tesseract is a Lemmy alternative front-end UI, it has nothing to do with the OCR, besides sharing the same name.
Also, Tesseract does not actually use a hard-coded list - that turned out to be misinformation by the LLM-written OOP. In actuality, there is a “toxicity filter” that admins can toggle on or off as they please - the polar opposite of a hard-coded feature. (Edit: there seems to be two lists, and while at least one is definitely not hard-coded, the status of the other is less clear, at least to me, and might be hard-coded.)
Don’t believe everything that you read on the Internet - it is not all true.
That said, Tesseract is quite opinionated in its views, and instance admins who hold different ideologies than its author might want to actually read about which settings they want to have toggled or not, rather than merely accept the defaults.
Apparently it does use a hardcoded list. The list db0 discovered was hardcoded it was not possible to circumvent it. This second list, the one that gets pulled from dubvee’s server can be disabled by the end-user that is if they somehow realise this antifeature even existed and they figured out that it was possible to disable in the settings. There’s also something to be said about not allowing the admins to disable it, but every user has to disable it individually for themselves.
The first list is not hard-coded, as it depends upon an instance-set environmental variable.(Edit: I retract this statement as I may have gotten confused between the differences between the two lists.)This other, hidden list though… that one is a lot more dicey. It can also be disabled wholesale, but is not easily discoverable nor editable, it is essentially his personal blocklist shared with everyone who uses Tesseract. (It could be nice to open that up as a more fully fleshed out feature where instance admins can more readily control whose personal blocklist gets pointed at, or even allow an individual end-user to input one?)
Though his latest manifesto says that it can be disabled, both by instance admins and by individual users (Edit 2: or maybe not? Admins can disable the ability to users to UNBLOCK the content, but not as readily simply disable the blocking in the first place?).
Anyway since it can be disabled, it’s not a “hard-coded block list”, as in mandatory.
No he even wrote it into tesseract himself apparently, taken from what you called his manifesto:
and readily admits
Yes, I am glad for db0’s correction. I already edited my comment that you replied to here but our messages got crossed while you were typing, anyway thank you for this clarification as well.
It seems like instances on ptz’s personal shitlist need to use db0’s fork from now on, or like blahaj just abandon Tesseract altogether (as you pointed out, the author even asked for thus:-P).
I was objecting to your claim that admins can disable it. This is not possible by design, every user has to do it individually.
Fair, that is the part that I know the least about but at a glance… it does look like you are correct. I will edit my comment above to reflect.