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.
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.
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
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.
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, 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.
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
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.