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