Can I as a user see which of these settings an instance has enabled?
Fediverse
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, Mbin, etc).
If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration)
"You can be pretty sure anyone with 1488 or even just 88 in their user name is a nazi, for example.
Speaking of which, PieFed has an optional approval queue for new registrations. New accounts with “88” in their name are always put in a different /dev/null queue that leads nowhere. The UI tells them they’re waiting for approval but that approval will never come."
https://join.piefed.social/2024/06/22/piefed-features-for-growing-healthy-communities/
This is ham-fisted.
People born in 1988 or August 8th or people of east asian descent might all like the number 88 or 888888
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

This

I want to do the downvote thing but I can't help but upvote this low reputation comment...
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.
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.
Those checkboxes have been there since version 0.9. Ages.
The problem with grabbing small snippets of code is a lot of context is lost. Don't trust anyone who does that. PieFed has 50,000 lines of code so anyone showing you 50 lines is leaving out 99.9% of the picture.
The problem with grabbing small snippets of code is a lot of context is lost.
To me, it was obvious that these parts were configurable. There were literally boolean checks for it.
But these features remind me Reddit. And I'm pretty sure most users simply unaware about these things enabled on the .social instance.
Clean, simple code that is easy to understand and contribute to
The problem with grabbing small snippets of code is a lot of context is lost. Don't trust anyone who does that. PieFed has 50,000 lines of code so anyone showing you 50 lines is leaving out 99.9% of the picture.
These 2 statements are incompatible.
Plus depending on the snippets they definitely can tell how things work
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_thing function 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
Wasn't the biggest concern and question why it didn't do an actual error message and is there any notes to say the performance impact having the 4chan filter on?
I'd also argue
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
Does absolutely nothing to assure people concerned about it being a thing. Like hiding it doesn't do anything about it being a thing
A lot of people looking at the code were saying these things were hardcoded, even after seeing an if statement which checks if the thing is enabled, which is straight up wrong unless you consider it hard coded because its coded, into the codebase.
unless you consider it hard coded because its coded into the codebase
That’s precisely the common definition and understanding of the term.
E: Sorry, I see what you mean in context now. I thought we were talking about a different piefed feature with a similar anti-4chan label that used a set of hardcoded strings to blacklist comments. Yeah, the tesseract image filter isn’t quite what I’d call hardcoded in and of itself.

