this post was submitted on 27 Aug 2025
49 points (96.2% liked)
Fediverse
21449 readers
9 users here now
A community dedicated to fediverse news and discussion.
Fediverse is a portmanteau of "federation" and "universe".
Getting started on Fediverse;
- What is the fediverse?
- Fediverse Platforms
- How to run your own community
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Can you point to the file in the pieced codeberg repo that hardcodes these blocks?
I need to understand if this is a block built into the software, or just an option the operators who deploy piefed have set in a blocklist.
It's a default option: https://codeberg.org/rimu/pyfedi/src/commit/f3e863d277932b55a15b1fe5043d750994fb8c14/app/cli.py#L116
Admins can obviously edit it later on, like those instances do:
Thanks for pointing that out.
That level of opinion in core infrastructure software is very inappropriate. This is disturbing
It would be better to default to dynamically pull from feediseer
That can definitely be improved. On the other hand,
List of Piefed instances that currently defederate hexbear:
https://piefed.fediverse.observer/list
As you can see, instances defederating hexbear are instances managed by teams which were going to do so anyway, as they already did on Lemmy. I'm still waiting for an example of an instance that defederated hexbear "by mistake".
Instances who want to federate know how to do so, as we've seen above.
Setting up an instance isn't trivial, assuming that admins would revise the defederation list doesn't seem realistic.
Recent comment from an admin
https://wetshav.ing/comment/92409
Now you're talking past me.
The issue is not that there is an option, the issue is not that there is even a suggested option.
The issue is a writer of core infrastructure software is putting their prejudices into the software as a default that have to be opted out of. That is antithetical to federation. That is pushing an agenda. That has no place in core infrastructure software.
Imagine if the Linux kernel by default, hard coded, blocked all IP addresses connecting to China, anybody could go in and remove those blocks, but they're there by default... Infrastructure should not have political opinions baked into it
We can go back and forth about wither this has had a material impact. That's not actually important. What it demonstrates is this software project is not mature yet. They still have too many emotional biases baked in.
I half expected them to have the Lemy.lol block baked in, thankfully they didn't, but it wouldn't have surprised me if they did.
As I said above,
What I expect down the line is that there will be a (y/n) option during setup that will allow admins to choose.
As of now, it's not a priority, there is bigger fish to fry. Piefed 1.2 is around the corner (https://codeberg.org/rimu/pyfedi/projects/19472 ), with many improvements that have been required for a while (e.g. communities and username autocompletion)
Let's also not forget that for years Lemmy had a built-in, activated by default slur filter impacting all users, people still used Lemmy even with that in place.
Lots of people made a fuss about it, which is the reason we eventually removed it from the defaults.
I'll edit the comment, along the lines of 'people were still using Lemmy even with that in place'
edit: done
I don't know, this level of what about ism feels like an attack on a very real and legitimate issue
Absolutely I agree that pie feed does great things, and they're updating, but 100% this is a real legitimate issue. And it needs to be addressed.
Given this is the only place I have found this discussion happening in a productive way, we shouldn't sidetrack it.
Basically we're talking about the lead developer maturing and removing their opinions. It takes almost zero effort to code that, but it might take a lifetime of effort for them to come to that position.
I understand other commenters frustrations with your counters, it feels like a dismissal, this is a real problem affecting real users today and they have legitimate grievance. If they want to organize, that is very reasonable.
Let me just reach out to the admin I quoted above. I'm not sure about the details of what they had to do during setup, maybe it's even easier that we thought.
There is this post as well: https://hackertalks.com/post/15572214?scrollToComments=true
Comment from Rimu there: https://hackertalks.com/post/15572214/10757273
Other commenters also state that changing those settings requires to fork the project, when it's just a settings modification
https://lemmy.zip/post/47272125/21126381
Frustration goes both ways
Edit: I did, I just pinged you there: https://hackertalks.com/post/15572214/10761436
Thank you for providing links on my home instance, that is very considerate of you
I don't think it matters how easy it is to opt out, the fact that a political opinion is the default is the problem.
A fork is appropriate, to remove the political opinion, it can follow the other project with the modification to the block list.
This comment implies that admins need to create a fork to modify the federation list. This is incorrect, it's a configuration change.
For instance I use pipe pipe which is a fork of new pipe plus sponsor block, because the new pipe developers decided sponsor block wasn't good philosophically
If new pipe gets an update, pipe pipe updates, and it rolls through a couple hours later. No big deal.
Indeed, I agree with what you are saying, but the quoted comment is still incorrect. A fork is not required to change the configuration of the federation list.
A fork could be made later following what you just said, but that's not what was being said in the quoted comment.
I have no interest in debating your quoted comment from above. I'm as an individual saying a fork makes sense to get around the strong political opinions of the developer.
All good then, see you around