In the admin back end video produced to show the features of the software, these sites were said to be “defaults” by the software creator, and they are prefilled in. You can change them after the fact, this is true, but if you simply spin up the instance and never touch those settings they are defederated. I know this is true, because I am in contact with an admin who manages a PieFed instance that is federated with Hexbear, they had to remove the Hexbear defederation after initial setup.
Dude, I specifically spoke to wjs (one of the main contributors to this project) about this claim - and he examined the code. It doesn’t do what you claim it does. That quote is directly from him. Hexbear and Lemmygrad are automatically defederated but if you remove them and them remove all the defederations entirely, it won’t just repopulate them with those instances and automatically add lemmy.ml.
Lemmy.ml was never a default in the first place when it comes to defederation. Piefed.social doesn’t even defederate lemmy.ml.
I’m telling you that Hexbear.net is on by default, and so is lemmygrad.ml. They both need to be removed from your settings before you can federate with them. There shouldn’t be any default instances period.
Hexbear and Lemmygrad aren’t Lemmy.ml. I never claimed that hexbear and lemmygrad aren’t defederated by default.
The claim you’re linking to though also alleges that lemmy.ml is automatically defederated, and that if you wipe all defederations entirely it will repopulate them back.
Ok, you have this completely off base about it “not doing anything”. While I might be wrong about it defederating, what this code ACTUALLY does is rate other instances defederation lists based on this hard coded list. Let me explain:
The site_instance_chooser_view() function in /app/api/alpha/views.py provides a JSON representation of the current site’s metadata for the instance chooser feature. This feature allows users to browse and compare different Fediverse instances before choosing one to join.
Within site_instance_chooser_view(), the defed_list variable is defined as follows (lines 1148‑1151):
This query retrieves only four specific domains from the BannedInstances table:
hexbear.net
lemmygrad.ml
hilariouschaos.com
lemmy.ml
The resulting list is used to populate the defederation field in the returned JSON (line 1187):
'defederation': list(set([instance.domain for instance in defed_list])),
The defederation field is part of the site metadata returned by the API endpoint /api/alpha/site/instance_chooser. This endpoint is called by the instance‑chooser UI (/auth/instance_chooser) when a user clicks “More” on an instance card.
The template app/templates/auth/instance_chooser.html uses the defederation list to compute a defederation quality rating. The rating is based on how many of the four watched domains are blocked:
≥3 blocked → “Good”
2 blocked → “Ok”
1 blocked → “Minimal”
<1 blocked → “Negligent”
This rating is displayed in the instance details modal under the “Defederation” label (line 114 of the template).
The UI also contains commented‑out code (lines 124‑130) that would show individual status indicators for each of the four domains, but this is currently disabled.
This is problematic for a number of reasons, most of all is that this rating that it generates is NOT transparent to the user. This page is used on PieFeds main page when you go to register, it’s part of the instance picker. The defederation rating under More is where this shows up. For instance, this means that instances like anarchist.nexus have a “OK” rating but instances like multiverse.soulism.net have a “GOOD” rating.
So the Defederation rating has an OBVIOUS BIAS that isn’t explained to the users at all. Not only is the bias not explained it doesn’t even contain all of the FASCIST INSTANCES IN ITS CALCULATION.
This is problematic for a number of reasons, most of all is that this rating that it generates is NOT transparent to the user. This page is used on PieFeds main page when you go to register, it’s part of the instance picker. The defederation rating under More is where this shows up. For instance, this means that instances like anarchist.nexus have a “OK” rating but instances like multiverse.soulism.net have a “GOOD” rating.
Okay, fair enough. I’d actually argue that the field doesn’t really make much sense to new users in the first place without context. “Good” is obviously loaded with bias preference in this context, but “Minimal” doesnt’ necessarily convey an negative opinion just based on the word itself. I could ask him to add more instances here (although the fascist instances that I know of here are so minor and obscure that they likely didn’t enter his mind - except hilariouschaos) and/or change the wording and add a description so its meaningful.
Also to detach the code so other join.piefed pages can rip it out or isolate their own instances they suggest disfavour towards.
In the admin back end video produced to show the features of the software, these sites were said to be “defaults” by the software creator, and they are prefilled in. You can change them after the fact, this is true, but if you simply spin up the instance and never touch those settings they are defederated. I know this is true, because I am in contact with an admin who manages a PieFed instance that is federated with Hexbear, they had to remove the Hexbear defederation after initial setup.
Dude, I specifically spoke to wjs (one of the main contributors to this project) about this claim - and he examined the code. It doesn’t do what you claim it does. That quote is directly from him. Hexbear and Lemmygrad are automatically defederated but if you remove them and them remove all the defederations entirely, it won’t just repopulate them with those instances and automatically add lemmy.ml.
Lemmy.ml was never a default in the first place when it comes to defederation. Piefed.social doesn’t even defederate lemmy.ml.
I’m telling you that Hexbear.net is on by default, and so is lemmygrad.ml. They both need to be removed from your settings before you can federate with them. There shouldn’t be any default instances period.
You should probably re-read what Skavau said. They’re talking specifically about lemmy.ml
Ah yeah I see that. It still doesn’t change my position on if the system should have defaults.
Hexbear and Lemmygrad aren’t Lemmy.ml. I never claimed that hexbear and lemmygrad aren’t defederated by default.
The claim you’re linking to though also alleges that lemmy.ml is automatically defederated, and that if you wipe all defederations entirely it will repopulate them back.
Ok, you have this completely off base about it “not doing anything”. While I might be wrong about it defederating, what this code ACTUALLY does is rate other instances defederation lists based on this hard coded list. Let me explain:
The
site_instance_chooser_view()function in/app/api/alpha/views.pyprovides a JSON representation of the current site’s metadata for the instance chooser feature. This feature allows users to browse and compare different Fediverse instances before choosing one to join.Within
site_instance_chooser_view(), thedefed_listvariable is defined as follows (lines 1148‑1151):defed_list = BannedInstances.query.filter(or_(BannedInstances.domain == 'hexbear.net', BannedInstances.domain == 'lemmygrad.ml', BannedInstances.domain == 'hilariouschaos.com', BannedInstances.domain == 'lemmy.ml')).order_by(BannedInstances.domain).all()This query retrieves only four specific domains from the
BannedInstancestable:hexbear.netlemmygrad.mlhilariouschaos.comlemmy.mlThe resulting list is used to populate the
defederationfield in the returned JSON (line 1187):'defederation': list(set([instance.domain for instance in defed_list])),The
defederationfield is part of the site metadata returned by the API endpoint/api/alpha/site/instance_chooser. This endpoint is called by the instance‑chooser UI (/auth/instance_chooser) when a user clicks “More” on an instance card.The template
app/templates/auth/instance_chooser.htmluses thedefederationlist to compute a defederation quality rating. The rating is based on how many of the four watched domains are blocked:This rating is displayed in the instance details modal under the “Defederation” label (line 114 of the template).
The UI also contains commented‑out code (lines 124‑130) that would show individual status indicators for each of the four domains, but this is currently disabled.
This is problematic for a number of reasons, most of all is that this rating that it generates is NOT transparent to the user. This page is used on PieFeds main page when you go to register, it’s part of the instance picker. The defederation rating under More is where this shows up. For instance, this means that instances like anarchist.nexus have a “OK” rating but instances like multiverse.soulism.net have a “GOOD” rating.
Anarchist.nexus has an “OK” raiding because they block Lemmygrad.ml (socialist) and hilariouschaos.com (MAGA instance)
multiverse.soulism.net has a “GOOD” rating because they block Lemmygrad.ml (socialist), Hexbear.net (socialist), lemmy.ml (operated by open communists).
So the Defederation rating has an OBVIOUS BIAS that isn’t explained to the users at all. Not only is the bias not explained it doesn’t even contain all of the FASCIST INSTANCES IN ITS CALCULATION.
https://piefed.social/auth/instance_chooser
The only measurements here seem to be stability.
“These servers are ordered by speed so it may vary depending on time of day, etc”
Click the “more” button and scroll down.
Okay, fair enough. I’d actually argue that the field doesn’t really make much sense to new users in the first place without context. “Good” is obviously loaded with bias preference in this context, but “Minimal” doesnt’ necessarily convey an negative opinion just based on the word itself. I could ask him to add more instances here (although the fascist instances that I know of here are so minor and obscure that they likely didn’t enter his mind - except hilariouschaos) and/or change the wording and add a description so its meaningful.
Also to detach the code so other join.piefed pages can rip it out or isolate their own instances they suggest disfavour towards.
How about not hard code this in the first place. If they are hell bent on this logic then let each instance admin list the instances they want to use?