Oh that’s good to hear. It sucks that people have to constantly fight the dev to keep his opinions out of the code though, must be tiring for all involved surely…

The two main lists that are implemented by default are a defederation list and huge huge listof blocked domains which includes wikileaks for instance, there are other lists (I don’t know if the “trusted instance” list comes prepopulated) and almost all can be emptied or added to. But that means that an admin that sets up the software has to go through a whole rigmarole to get the instance to neutral before being able to do what they think is best. And hope they didn’t miss anything.

In the case of the blocked domains it’s particularly grating since it has like 4000 entries that you either have to delete one-by-one or have to do a manual db transaction to empty the list and that is by design. Plus all you get as a warning that such a list exists is one line during the setup that says Added 'No-QAnon' blocklist, see https://github.com/rimu/no-qanon but it’s definitely not just QAnon links.

But then the admin isn’t managing the list the dev is! You have one guy managing a list across multiple instances, that circumvents the public modlog, where users do not know how they got on, or how they could get off, and the power to shadowban across multiple instances is concentrated in the hands of just one guy!

Huh?? It’s not up to the admin, that’s my point, the list is implemented by the dev and every instance that ran tesseract ran the same blocklist. My point is that it should be up to the admins of an instance, not the dev of software that gets deployed on multiple instances…

And every user that uses that software for whatever reason, superior features, easier on the eyes, more popular it’s what everyone recommended will get their curation from that one dev.

The issue is that it’s one person shadowbanning people without their knowledge for any arbitrary reason across instances. Like even if it’s opt-out, that’s still problematic since it makes the default experience whatever that one person thinks it should be. Why should one guy get to decide across the entire fediverse whether your posts are opt-in? That is antithetical to the very concept of the fediverse.

Refactored their existing “enable toxicity mode” feature into a clearer, toggleable blocklist feature

No! The whole point of the fediverse is not to have centralised blocklists. Having blocklists baked in to the code, especially ones that get updated in a centralised manner with no accountability and without telling users they’re on it is absolutely antithetical to the platform and one of the main reasons why people are leaving reddit and coming here. If you want to curate the experience of a user in that manner, what you do is open an instance and advertise it as such. That way people can, at least on lemmy, know where they’re banned from without having to dive into the code or pull API endpoints manually. In fact how a lemmy instance federates and how it curates this experience is one of the distinguishing features among the instances. You have instances like lemmy.zip that federate all that will have them, instances like hexbear that are very quick to defederate in order to keep a safe-space and instances like blahaj that are somewhere between.

A front-end (or any piece of code that is made for being deployed on multiple instances) should be agnostic to all of this. It’s up to the admins of the instances and not the devs to curate and this is one of the main reasons why I don’t trust the piefed dev. Sure you can disable almost everything, but that still means that an admin has to do work in order to get to a neutral place from where they can then curate.

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.

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.