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.
this post was submitted on 27 Aug 2025
48 points (96.2% liked)
Fediverse
21417 readers
38 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
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:
- https://piefed.zip/c/news@hexbear.net
- https://piefed.zip/instances?page=9&filter=federated&search=
- https://piefed.au/instances?page=6&filter=federated&search=
- https://anarchist.nexus/instances?page=4&filter=federated&search= , which is related to https://lemmy.dbzer0.com/, also federated with hexbear
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.blahaj.zone/ , the same way https://lemmy.blahaj.zone/ does
- https://piefed.world/, the same way https://lemmy.world/ does
- https://piefed.ca/, the same way https://lemmy.ca/ does
- https://feddit.online/, the same way https://fedia.io/ does (by the way, Fedia isn't a software, it's called Mbin, and doesn't have such code, so not sure why you're including them into your title)
- https://quokk.au/, it used to be the same when it was still a Lemmy instance
- https://piefed.europe.pub/, the same way https://europe.pub/ does
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
This is exactly how it works. I started a PieFed instance and made the decision (during setup) to trim the defederation list down to none. Users can block on the account level.
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,
That can definitely be improved.
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, still nobody made a fuss about it, admins just disabled it and called it a day.
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.
Given this is the only place I have found this discussion happening in a productive way, we shouldn’t sidetrack it.
There is this post as well: https://hackertalks.com/post/15572214?scrollToComments=true
Comment from Rimu there: https://hackertalks.com/post/15572214/10757273
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. .
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.
- Trying to help, I know how tedious it can be sometimes
- As I said, it can be improved, but we probably disagree on the importance on that problem. It's minor for some people due to how easy the configuration can be changed, it's more important for other people. Everybody will have their opinion on the matter.
- I think you misunderstood. Here's the comment I was referring too
I get not wanting to federate with specific instances but the way this works is to just automatically make it one way only unless the person using their fork manually changes it.
This comment implies that admins need to create a fork to modify the federation list. This is incorrect, it's a configuration change.
- It is just a configuration change for the administrator of a specific instance. But if somebody wanted to make politics-free pie feed as a fork of the project, without the opinionated block list, but otherwise following the original project. That would be totally appropriate.
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
I have removed the piefed instances that did not unblock hexbear from our allow-list to prevent the one way federation
load more comments
(1 replies)
@dessalines@lemmy.ml @davel@lemmy.ml I am curious as to your thoughts on this. It is very annoying for myself and others to write out effort posts refuting shit these liberals spew on our platforms only to find out none of them will ever see it. Meanwhile we have to be subject to their garbage posts and takes with no recourse. This is fundamentally detrimental to the fediverse as a whole.
There's nothing we can do about server-to-server blocking, but I think over the long term, people will join servers that do less instance blocking, so that they can personally be in control of what they see.
And of course everyone not on restricted servers will still see your replies / takedowns, so it really only harms them. In a big way, responses are just as important to onlookers, than the one you're responding to.
Oh yeah for sure I was just curious as to your thoughts on people taking this project and building in their own ideologically motivated blocking. I know that there is nothing to be done about it as its all open source I just find it scummy that they do this in the first place. I get not wanting to federate with specific instances but the way this works is to just automatically make it one way only unless the person using their fork manually changes it.
I don't want to force them to see our posts or comments or anything idgaf about that I just don't want to have to guess which people I can see on my end can actually see my replies to them ya know?
unless the person using their fork manually changes it.
Updating the defederation blocklist is done via the admin UI. A fork implies having to recreate the source code and modify it. This is different.
Recent comment from another admin
This is exactly how it works. I started a PieFed instance and made the decision (during setup) to trim the defederation list down to none. Users can block on the account level.
Whatever, point still stands it's shady AF and you are obsessed with defending it and I really don't give a shit how you spin it.
load more comments
(5 replies)
view more: next ›