And that’s a large part of the issue. The frontend doesn’t actually disclose this blocklist at all. In fact, it actively takes steps to obfuscate things and make it appear as if the blocklist doesn’t exist at all.

For example, attempting to view a blocked instance shows a generic network error, rather than a “this instance is being blocked by your frontend” error. And blocked users aren’t simply flagged and/or collapsed. They’re entirely hidden, as if they don’t exist at all. So someone using this as their primary frontend wouldn’t even know that they’re missing entire posts and/or comment chains, because anything from the blocked users is simply gone.

Additionally, the blocklist is downloaded (in plaintext, over http) when the frontend is booted, so it’s not a file that gets updated with the git version updates. Meaning the dev can silently update it even if users haven’t pulled new versions. Simply rebooting your frontend would be enough to pull an updated blocklist. This gives the dev an extreme amount of censorship power, because they can effectively change users’ configs without any action on the users’ part.

It was only originally discovered because the admin for db0 used the frontend. And notably, db0 is on the block list. They were previously using an old version of the frontend that didn’t include the hidden blocklist yet. They updated their Lemmy stack a little while ago, and suddenly their entire frontend was broken (the entire feed was completely empty) and showing a generic version incompatibility error.

After lots of troubleshooting, the db0 admin eventually discovered that the frontend was downloading a hidden blocklist and automatically blocking the instance that it was running on. Because when they updated their stack, the new version of Tesseract included the secret blocklist. So it downloaded the blocklist when it booted up, found that db0 was on the list, and silently hid every single post because they were all from a blocked instance. This resulted in a completely empty feed.