A few people in the other thread assumed that it was required to fork the code to disable those filters. That’s not the case, the filters can be configured, and are off by default.
To hide the reputation system, here’s a line of CSS that admins can add in the admin area to hide it for every user
That CSS line can also be used by any user wanting to hide the score at the user level.
That’s admin and community dependent - an admin or community can take that reputation metric and use it to automate moderation. There is/was an entire community whose whole gimmick was auto-banning users from every instance for activity across the entire federated network. But beyond that, piefed already drops content instance-wide for as little as a single user blocking another.
if parent_comment.author.has_blocked_user(user.id) or parent_comment.author.has_blocked_instance(user.instance_id): log_incoming_ap(id, APLOG_CREATE, APLOG_FAILURE, saved_json, 'Parent comment author blocked replier') return NoneThe codebase is riddled with shit like this.
There’s no inbuilt system to automation moderating out low reputation accounts to my knowledge. Any instance that would do this would have to be using a third-party tool.
The Piefed system of blocking is more aligned with how most other sites do blocking. Lemmy doesn’t prevent blocked users from replying, but Piefed does. So from Piefed, if it’s working properly, you shouldn’t be able to reply to users who have blocked you. Lemmy doesn’t operate like that, so it just throws out replies. It’s due to different blocking philosophies.
I don’t know any other site that allows blocked users to reply to the blocking user but deletes the reply on the backend server for everyone on it.
But regardless - that decision was made unilaterally by piefed and corrupts the federation of the rest of the network. Huge holes of mis-matched comment threads are being created everywhere because piefed chose to implement a destructive blocking system rather than a front-end filter, or by working with the other implementations on a solution that doesn’t misalign data across the network.
I understand that you agree with how piefed restricts certain content - my point is that the way piefed has implemented those features corrupts the integrity of the entire network. They’ve made it clear that they have no interest in collaborating with the other developers, even if it means creating incompatibilities between the integrations to the point of functional defederation.
“Move fast and break stuff” isn’t something anyone should be aspiring to.
It doesn’t. On Piefed if you are blocked, you should be unable to reply. It is whited out. But Lemmy obviously doesn’t work like that so incoming replies from users who are blocked, coming from Lemmy, just have it automatically thrown out.
Did Lemmy take a democratic vote about how they wanted blocking to be handled? Some users prefer someone they block being unable to reply to them. I have even seem this expressed on Hexbear.
What do you mean “made clear”? Has Piefed refused help or support from other developers?
Yes, that’s exactly what i’m pointing to. Rather than implementing this in a way that’s non-destructive and transparent, they’ve created an asymmetry by dropping comments entirely. They could render comments based on block-checks and not create this problem, but instead they chose to say ‘fuck the lemmy instances’ and create hundreds of holes in the federated activity out of seemingly nothing but spite.
Not “other developers” generally, “the other developers”. I’m speaking specifically of the already existing lemmy codebase. Piefed was created as an alternative to lemmy - at least in part - because of disagreements over the developer’s political views. It wasn’t because lemmy was poorly written, it was because a couple of developers decided they wanted to fork the project into their own that they could manage independently from lemmy.
How could Piefed make this disparity of blocking philosophy mesh with Lemmys here? If Rimu thinks that a block is a block, and that users who are blocked should not be able to go on replying to the user who blocked them, then I don’t see why he would carry comments just because they come from Lemmy.
Correct. But even if there was no ideological dispute here (he also disliked the development cycle and choices - I don’t want to make too many assumptions here), rimu may still have made his own reddit clone or someone else may have - which would handle things very differently.
Without forcing every server to adopt the same blocking system universally? It can’t. What it’s doing now is functionally no different than if they hid replies on the user front end for users blocking others outside the home instance, except instead of doing this non-destructively (and preserving data pairety across instances), they’ve decided to blow huge holes in the federation service that are no longer mirrored on the other instances.
If the piefed method of handling blocking is to make it impossible for all users in every instance incapable of replying to a user who has blocked them, then every server would need to adopt the same method universally. Piefed has every right to hide content from their users that their users have chosen to block, but doing so by rejecting that content for the whole server while the rest of the network carries on ends up creating shadow forums on every instance.
That would be preferable to the ‘embrace, extend, extinguish’ path that they are currently on.
Right, so it should be on Piefed to accept Lemmy’s blocking system even if Rimu disagrees with it?
This doesn’t bother me that much primarily because defederation differences can cause this anyway.
If a hypothetical lemmy-alternative existed, regardless of why, it could still cause disruption in all kinds of ways if there’s a fundamental design contradiction ethos.
Which is why it’s important for users to reject attempts at splitting the network into different codebases in the firstplace.
That piefed and many of its users reject working with lemmy devs on principle over political grievance doesn’t change or justify the fact that they are destroying the democratic nature of the federated network they’re taking advantage of.
Which is why defederation is a last resort and usually requires some democratic discussion as an instance. Same with instance-banning users - that ability is limited to admins, which means users can hold them accountable if there’s abuse. It’s a reason why i consider users who go out of their way to foment division against other instances or users over petty disagreements to be caustic and unwelcome, but are at least still working within a decentralized and democratic framework. When any user has the ability to create the same kind of holes in the network, all accountability vanishes and it starts to look like swiss-cheese.