Piefed admin settings that allow to enable or disable content filters (they are disabled by default, see body for details)
-
It’s one thing to empower admins with mod tools, it’s another to establish reputation ratings based on opaque rules, hide them behind fake error messages, and then enforce them using destructive workarounds that cause nothing but confusion to users and other federated server admins.
The reputation ratings of users are purely based on downvotes received, it's not really opaque.
The 4chan thing again, can be turned off.
Go ahead, be restrictive with who can participate on your server - that’s perfectly fine. But be transparent about how your moderation tools work and don’t hide punitive ranking systems in your codebase.
The reputation/attitude system is not concealed at all.
That isn't true - the comment filters also dock users reputation points, and without any notification to users that it's happening.
None of this is presented to users - that's the definition of opaque. They've shoehorned these features into their code without any notice to other users or instance admins, and have provided no way of notifying anyone of what is happening on the backside that might effect how content is handled or federated.
All of this irreparably injures the reputation of not just the piefed implementation but of the broader fediverse.
-
Rimu literally wrote about it a long time ago. All instance admins would also know about it.
https://join.piefed.social/features/
Also, everyone can see the little exclamation points on accounts that are heavily downvoted from Piefed.
This is like hiding changes in a 500 page TOS - is everyone who is impacted by this code going to know to look at this thread any time a new way of fucking with user reputation calcs is introduced?
Absolutely not.
-
That isn't true - the comment filters also dock users reputation points, and without any notification to users that it's happening.
None of this is presented to users - that's the definition of opaque. They've shoehorned these features into their code without any notice to other users or instance admins, and have provided no way of notifying anyone of what is happening on the backside that might effect how content is handled or federated.
All of this irreparably injures the reputation of not just the piefed implementation but of the broader fediverse.
This can be turned off by instance admins who would see this in their settings. I agree maybe a public-facing form here could be of use though.
-
This is like hiding changes in a 500 page TOS - is everyone who is impacted by this code going to know to look at this thread any time a new way of fucking with user reputation calcs is introduced?
Absolutely not.
Every single instance admin will know about it too. The reputation/attitude system did not just get quietly added a week ago.
-
This can be turned off by instance admins who would see this in their settings. I agree maybe a public-facing form here could be of use though.
There's nothing in the code that I can see that indicates that any of the penalties are undone by turning off the filter - but that's kind of the point. They've introduced a new metric that thumbs the scale of content visibility that's hard-coded and inscrutable to everyone but those with knowledge of the codebase, and that makes the entire project and the devs who made those choices un-trustable.
Is there a version of their reputation system that's less objectionable? Sure. But it would need to be exceedingly transparent with clear documentation on how to configure, alter, and revert if there's a mistake made. But there's nothing here that indicates the devs of piefed are willing or capable of transparency or even just clear documentation.
-
There's nothing in the code that I can see that indicates that any of the penalties are undone by turning off the filter - but that's kind of the point. They've introduced a new metric that thumbs the scale of content visibility that's hard-coded and inscrutable to everyone but those with knowledge of the codebase, and that makes the entire project and the devs who made those choices un-trustable.
Is there a version of their reputation system that's less objectionable? Sure. But it would need to be exceedingly transparent with clear documentation on how to configure, alter, and revert if there's a mistake made. But there's nothing here that indicates the devs of piefed are willing or capable of transparency or even just clear documentation.
Have you or anyone attempted to ask rimu about this? I don't ever recall any piefed instance owner asking this.
He has already altered or rolled back a ton of functions due to scrutiny.
-
Every single instance admin will know about it too. The reputation/attitude system did not just get quietly added a week ago.
Is there any indication to users interacting with those instances that their content is being limited by metrics that may or may not be visible to them, and by rules that may or may not be documented anywhere but the piefed codebase?
These are wildly hostile features to anyone not using piefed, and it's feeling a bit like that's the point.
-
Is there any indication to users interacting with those instances that their content is being limited by metrics that may or may not be visible to them, and by rules that may or may not be documented anywhere but the piefed codebase?
These are wildly hostile features to anyone not using piefed, and it's feeling a bit like that's the point.
The reputation system doesn't shadowban content. You don't get comments silently autoremoved for having a low reputation. You don't get throttled either.
-
Honestly I don't mind if it would be visible to the users. Like how long would this be secret if it wasn't for the code audit.
I mean, I disagree, but that's my own preference.
Ranking/sorting/filtering systems should always be up-front and user-configurable, and their implementation should be instance-agnostic. Hiding it in the code is definitely the worst part of this, but far from the only problem.
-
Previous threads about these filters were people complaining about them being hardcoded, completely ignoring that they are completely optional and off by default. It would go something like this:
Look at this awful thing PieFed does!
def do_the_thing(): # relatively simple code that does the thing
It completely ignored the context that the
do_the_thingfunction is only called if the admin wants to do the thing.Most of the issues people have brought up have been about why the snippets are even in the code not trying to obscure what the code does.
It completely ignored the context that the do_the_thing function is only called if the admin wants to do the thing
Again it's why is this a thing
-
Simple != few lines of code, nothing incompatible about those two statements
Saying the simple code needs lots of context outside of the code block says it's either not simple or not easy to understand
-
The reputation system doesn't shadowban content. You don't get comments silently autoremoved for having a low reputation. You don't get throttled either.
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.
-
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.
-
Have you or anyone attempted to ask rimu about this? I don't ever recall any piefed instance owner asking this.
He has already altered or rolled back a ton of functions due to scrutiny.
I'm not collaborating with a developer who has it out for the platform I'm working to improve. If he wants to fix the shit he broke, he can.
-
I'm not collaborating with a developer who has it out for the platform I'm working to improve. If he wants to fix the shit he broke, he can.
Then I don't know what you expect. He does respond to criticism.
-
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.
The Piefed system of blocking is more aligned with how most other sites do blocking
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.
-
Is there anyway for users to know which piefed instances have this and the other censorship settings enabled? I was trying to upload an image the other day and kept getting an error and now i realize it was because of the code itself?!
Like why the fuck wouldn't it tell me that image isn't allowed instead of giving me an error
Edit: to be clear, your point is a good one, I am talking below about the discussion going on in the link.
lolz, so much disinformation there though. Like:
What’s sad is that since lemmy.ml is blocked by default, most PieFed users won’t see it.
I think there might be one major instance that chose to do this, and I cannot even recall offhand which one, so obviously it's not THAT major. This is some LLM-level of analysis right there (Lemmygrad.ml and hexbear.net are blocked from many instances, and people often lump lemmy.ml together into a triad, hence lemmy.ml must be automatically blocked as well!).
Funny enough, Lemmy.ml disallows what they consider cuss words, which were even hard-coded, and when asked they told the community to take a hike ("create a fork and stop bothering us about it"), until after a huge outcry they did eventually relent.
Lemmy users be like "why can't we all get along...", yet feel absolutely free to criticize every tiny aspect (including - in fact especially - fictional ones) of PieFed, while ignoring how e.g. lemmy.ml kicks people out of communities they've never even so much as heard of for not praising Russia, China, or North Korea hard enough.
My side always does good and never bad, other side always does bad and never good. Much tribal, so cringe.
-
The Piefed system of blocking is more aligned with how most other sites do blocking
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?
-
Saying the simple code needs lots of context outside of the code block says it's either not simple or not easy to understand
« The problem with grabbing small snippets of code is a lot of context is lost.» does not mean that a lot of additional code is required to understand the context, additionally, simple code may require you to read a bit of code to understand it.
Simplicity does not mean small scale, nor that it must be understood at a glance.
Rich Hickey got a great presentation where he discuss simplicity vs complexity. It's worth a watch if you want to better understand the concepts.
-
It's as if someone saw a federated social media codebase that enabled the free movement of users and expression online and though, "someone should fix that".
It isnt that the codebase 'forces' moderation decisions - it's that it's undoing the work done in the lemmy codebase to flatten moderation across instances and make them transparent, and introducing arbitrary metrics that can be used to limit the visibility of expression not just on the local instance but across many
You're free to use whatever software on your server you like, but IMO these 'filters' are petty, low-effort workarounds to features in the lemmy codebase that are what make it truely democraticand decentralized, and they degrade the health of the entire federated network by extension.
Okay so you have some good points, especially towards the beginning, but just so we are on the same page: are you aware that moderation reports do not federate? Or rather, that they do in PieFed but not in Lemmy. Things are rarely so black and white, good and evil, healthy or not. (I forget, will Lemmy 1.0 add this capability? Anyway PieFed already has it.)
introducing arbitrary metrics that can be used to limit the visibility of expression
Investigate just a tiny bit into the moderation practices going on at lemmy.ml.
not just on the local instance but across many
That one is harder to investigate but there too - Lemmy devs (who also are the same ones moderating lemmy.ml, and yes monetary funds donated towards "Lemmy development" absolutely go to that, rather than code changes, with no way to opt out of that, unless you donate to Nutomic directly, which brings up... shall we say other issues relating to limitations on free expressions, particularly for trans people) in the last year added a hard-coded instance name that can provide a list of which communities it wanted to suggest to new instances as being popular, essentially giving that instance veto power. ONE instance, controlling all new instances, unless the admin does additional work to discover those shadow-banned rejections and add them manually.
Take one guess which instance was chosen to have that veto power? Yeah, lemmy.ml, surprise. Tbf, this has since been walked back, and while the instance names are still hard-coded, the new instance admin now has multiple options that they can select from (so the selection of any particular one of those is not, anymore). I am not sure how transparently this is presented to them.
Things get better with time and even more with attention. The PieFed devs are extremely receptive to feedback. The Lemmy devs... well, they are at least somewhat receptive - tbf Rust is a difficult language and that seems to constrain how much they are willing to do in any given timeframe (unless there is some other reason that requests go for years and years and years without being done?). Lemmy is just older, and also it receives funding (except again, it is exceedingly difficult to ensure that such funding actually goes towards code development), so then in that light, PieFed's development is SUPREMELY impressive. Yes more work will need to be done with it still.
Let's get busy and make the Threadiverse healthier - all of us, together!?:-)
