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.
There is a very much hardcoded list of instances that determine whether a piefed instance is considered to have a good “defederation policy” or not.
As far as I understand it, it’s not “hardcoded” in the sense that all piefed instances have it (otherwise I wouldn’t be able to respond to you).
From what I understand, there is a default list, but this can be edited by any instance admins.
No! There is a hardcoded instance list to determine whether a piefed instance is considered to have a good “defederation policy” or not. All piefed instances have this if they didn’t fork the code.
https://codeberg.org/rimu/pyfedi/src/commit/881a5c95657b03c29e81ac8f619e4d26e4f6973d/app/templates/auth/instance_chooser.html Line 562
// Handle federation status const watchedDomains = { 'hexbear.net': 'hexbear-status', 'hilariouschaos.com': 'hilariouschaos-status', 'lemmygrad.ml': 'lemmygrad-status', 'lemmy.ml': 'lemmy-status', 'gregtech.eu': 'lemvotes-status', }; const defederatedDomains = instance.defederation || []; countDefederated = 0; Object.entries(watchedDomains).forEach(([domain, elementId]) => { const statusElement = document.getElementById(elementId); const isDefederated = defederatedDomains.includes(domain); if (isDefederated) { countDefederated += 1 } }); if(countDefederated >= 3) defederationQuality = 'Good'; else if(countDefederated === 2) defederationQuality = 'Ok'; else if(countDefederated === 1) defederationQuality = 'Minimal'; else if(countDefederated < 1) defederationQuality = 'None';So you could defederate the “tankie triad” but not hilariouschaos.com, lemmychan and whatever else harmful instances and be considered to have a “good” defederation policy. This is what is shown to new users to make a decision which instance to join but it is impossible to find out on what basis this grade is assigned except for diving into the code. And it cannot be altered except for forking.
Thank you, this is an extremely helpful description.
Btw neither fedinsfw.app (with 2.4x higher number of MAUs than PieFed.social, making it by far the #1 most-used PieFed instance), nor PieFed.zip (with self-reportedly 541 MAUs, making it the clear #3 PieFed instance) show up in that instance picker list.
I tried viewing the list from multiple instances including from PieFed.social itself. So I’m not sure how much people actually make use of that picker, and it seems buggy as hell (unless both of those instances have intentionally decided not to be listed?). Though even more confusing is how PieFed.zip also does not report onto https://piefed.fediverse.observer/list (though Lemmy.zip does appear at https://lemmy.fediverse.observer/list).
Anyway, it’s good to know that while PieFed does not have a hard-coded instance blacklist - nor are those 4chan filters hard-coded either iirc - it does have an extremely odd and unhelpful depiction of what constitutes a “good” level of defederation on that instance picker list.
And now with the highly controversial and extremely bad roll-out of the vote quota issue, while I would not go so far as to recommend that people steer clear of PieFed itself (instances like PieFed.zip and quokka and blahaj seem to be doing just fine with it, e.g. maintaining a watchful eye on the opinionated additions to the sourcecode), I would unequivocally recommend avoiding trusting the instance picker at this point. As you showed and I piled onto here, it is just an absolute mess (and Rimu is showing strong signs of burnout so unlikely to be fixed anytime soon).
Precisely. We could point people to the very dictionary definition of the word, but it seems not to change many people’s mind who have already decided which “camp” they want to be in, and that they will (attempt to) preempt the word to mean… whatever they feel like.
Therefore, a statement like
IF (instance-set-variable) THEN { ... implement block }is by definition not “hard-coding”, bc it asks the instance admin what value it wants for that variable, and then only conditionally runs the code to set the instance block if the admin asks it to.
There are plenty of things to criticize PieFed for, but “hard-coding instance blocks” is not one of them. (
And now it seems the same error was made regarding Tesseract.Edit: this point is terribly unclear but probably not correct, as in one of the two blocklists is definitely not hard-coded but the other seems to be.)The same error was not done regarding tesseract. It absolutely hardcoded instance blocks.
apparently there is some env var
PUBLIC_ALLOW_TOXIC_MODEthat disables the entire list. From https://github.com/db0/tesseract/blob/c6767607da9f08033bbc38c2c3e38975be0eef2e/src/lib/policies/system.ts#L89export async function updateSystemFilterPolicy() { SYSTEM_POLICY.set(BLANK_SYSTEM_FILTER_POLICY) return if (SBDisabled && get(userSettings).enableToxicMode) { SYSTEM_POLICY.set(BLANK_SYSTEM_FILTER_POLICY) return }dunno if it actually works as intended tho. Also the main repo got deleted apparently lmao
Yes for the second blacklist, if you knew that you were getting things filtered out in the first place and if you knew to look for the setting and find it.
But the first blacklist, the one I discovered, which prevents you from even using an instance whatsoever, is completely hardcoded with no way to bypass.
Thank you for the clarification and for making the fork, that seems like it will be very useful if you want to continue with that front-end UI.
Edit: I edited my statement above and will try to do similarly for others where I have been wrong.
ah thanks for the clarification
Forgot: They didn’t delete it. They renamed it then reversed its history to 2023 so that I can’t sync any more changes to my fork and my commits telling him to eat shit are not visible in the repo diff. lol
Please see my comment spelling it out in detail https://lem.lemmy.blahaj.zone/post/45697068/21461570
this is also a very backwards telling of events when people keep calling us “tankies” and “stalinists” or whatever whenever someone dares to say something outside the US State sanctioned lines about foreign policy.