shit
piss
fuck
cunt
cocksucker
motherfucker
tits
memes
piracy
196
greentext
usauthoritarianism
enoughmuskspam
political_weirdos
4chan
Seems like one of the PieFed devs has some opinions about the kind of content they dislike, and are unilaterally forcing that on every PieFed instance. I can somewhat understand filtering out curse words, but specific communities should not blocked by default, and definitely not hidden in a hardcoded list in the source code.
Edit: Important context here: https://lemmy.world/comment/21323475 Seems this blocklist is more limited in scope; it’s not blocking federation entirely, just blocking (from what I can tell) their appearance in search and automatically federating with them when adding an instance. Still problematic to exclude specific communities in a non-configurable way with little justification IMO.
The latter I guess could be used to stop Musk spam (since the community is literally nothing but Elon Musk news) but not allowing the word “memes” in a community name?
Utterly stupid.
But they do appear to be fans of Carlin based on the first 7 banned words.
There’s no racial slurs in there either. I might have assumed this was merely an example an operator is meant to edit themselves, but these are some weird ass choices for even that.
Ok thats based af. It’s not about stopping one idiot, it’s about saving thousands of people from being subjected to discussion-derailing derailing drivel.
There may also be a misunderstanding, or perhaps this argument is only one of those that only looks smart from far away, but either way to clarify: this list isn’t truly a filter list, it’s a listing of community NAMES that will get filtered out.
For one thing, (sadly) there aren’t so many Latin-speaking instances in the Threadiverse?
So is it really “stupid” then, to block communities that don’t even exist? ich_el would be an example of one that would actually exist, although I don’t think that one needs to be filtered out. I was saying that if there is really truly one that should be filtered, then it could be added to the list?
If someone wanted a less ah… “argumentative” subset of the Threadiverse, then I could see how filtering out “fuck_cars” would achieve that end (not that I agree with having such a listing, or in the exact contents of this one, but I do disagree that it is “stupid” as in ineffectual to have made the list in this way - it is achieving some kind of a purpose, and with people’s help that purpose could itself be changed, or if kept intact then the list enhanced to function even better than it has been doing so far).
But the “tits” filter can apply to “partits” (Catalan, means parties in English) or “partitsocialista”. And now there are no communities with those names… but what if someone in the future wants to create them?
So if I started a piefed instance and wanted to host a 196 community I’d have to edit the list, but would every single other instance also have to or no?
Or you could pull it in manually. It’s just that the automated startup would not do it for you, for communities with these keywords. Nothing prevents anyone from pulling in the communities manually though.
Each instance should be free to set their own rules. Individual instances blocking those communities is fine, but the PieFed devs hardcoding a blocklist that applies to all instances (especially one as opinionated and arbitrary as this) is absolutely not.
Each instance should be free to set their own rules.
They… are though? Maybe I am dumb, but I do not understand why each instance setting its own rules would apply to all other instances? Say if you made your own instance, you would set your own rules, but the other instances are free to set theirs as well? Like if you want to allow communities such as “4chan”, then go ahead, but if others want to block that, then why shouldn’t they be allowed to?
Definitely agree that this issue should be made much more transparent and easier to change, like not hard-coding it.
This filter is not part of any specific instance, it’s hardcoded into PieFed’s code. That means it applies to every PieFed instance unless the instance admin explicitly patches the code to remove it.
As mentioned elsewhere, it’s just a convenience function - anytime after starting up the instance, the admins can always pull in those communities manually. Or change this part of the code beforehand. So it’s not a hard-coded “block”, just slightly less convenient for it to not automatically pull in those communities during the one-time initial setup for an instance.
But anyway you are right that this should not be a hard-coded list.
Edit: it’s also worth mentioning that the way that Lemmy does this is via a direct pull of communities from Lemmy.ml. What I am reacting to here is not so much to say that PieFed’s method is perfect, but that both suffer from flaws, and that PieFed’s is relatively benign, at least in comparison to Lemmy’s. Lemmy uses an extremely authoritarian approach whereby Lemmy.ml is the sole and invariant arbiter of what communities are allowed vs. not during that initial one-time setup, and there is no way to change that, whereas PieFed uses a list that the instance admin is capable of changing. On the spectrum of authoritarian control, PieFed’s level here is like a 1 out of 100, whereas Lemmy’s is… well, it’s still not much in this exact situation, but it’s definitely way more. Sorry for being confusing initially in the way I worded that.
I presume that it was a simple misunderstanding, but in any case it has lead to some… interesting, and ultimately quite fruitful discussion, so there’s that to have enjoyed:-).
And it really shouldn’t have been hard-coded like that. A minor issue imho, and one not really a problem until now, but at least it’s already now well on its way to being resolved. In contrast, Lemmy’s own hard-coding of Lemmy.ml into the equivalent function I doubt will ever be changed, certainly not without strong reluctance (and likely along with public outcry, as before with the filter list).
One point: I would argue that opt-in vs. -out doesn’t fully apply here, as this automated convenience function will only ever be run once upon initial setup for an instance, after which the instance admin can add any communities they desire, manually (I’m not sure why OP phrased it then as needing to be “debugged”, that seems an odd term for such routine instance maintenance tasks that do not need any modification of any code at all, anywhere?). In short, it’s not actually a “block” at all, as the wording in the meme seems to me to strongly imply by using “federate”). The phrase “opt-out” usually referrs to something harsh but that isn’t all the way fully forced, but this issue of not pulling in (initially) of communities is so extremely gentle than on the spectrum it is adjacent to “opt-in” already? Still, ultimately you are probably correct, I am just not sure of the wording there, so wanted to help by offering those additional nuances.
List of blocked words in community names:
shit piss fuck cunt cocksucker motherfucker tits memes piracy 196 greentext usauthoritarianism enoughmuskspam political_weirdos 4chanSeems like one of the PieFed devs has some opinions about the kind of content they dislike, and are unilaterally forcing that on every PieFed instance. I can somewhat understand filtering out curse words, but specific communities should not blocked by default, and definitely not hidden in a hardcoded list in the source code.
Edit: Important context here: https://lemmy.world/comment/21323475 Seems this blocklist is more limited in scope; it’s not blocking federation entirely, just blocking (from what I can tell) their appearance in search and automatically federating with them when adding an instance. Still problematic to exclude specific communities in a non-configurable way with little justification IMO.
They also put “memes” and “enoughmuskspam.”
The latter I guess could be used to stop Musk spam (since the community is literally nothing but Elon Musk news) but not allowing the word “memes” in a community name?
Utterly stupid.
But they do appear to be fans of Carlin based on the first 7 banned words.
There’s no racial slurs in there either. I might have assumed this was merely an example an operator is meant to edit themselves, but these are some weird ass choices for even that.
Well, it seems specifically 196 just got removed: https://codeberg.org/rimu/pyfedi/commit/b7a9ea0eea3a80f710e0b5b63cf0bbecde60f8bf
Actually, they only removed it from 2 places. It’s still there https://codeberg.org/rimu/pyfedi/src/branch/main/app/cli.py#L1026
Duplication of constants is a cherry on that whole cake of stream-of-consciousness code style.
Removed by mod
Got any other specific examples?
Removed by mod
That’s hilarious
Removed by mod
Ok thats based af. It’s not about stopping one idiot, it’s about saving thousands of people from being subjected to discussion-derailing derailing drivel.
Removed by mod
Removed by mod
Hard-coded filters, here we go again.
https://github.com/LemmyNet/lemmy/issues/622
I think a regex to filter out common slurs isn’t really the same
The regex:
Link to code
That can’t be common enough to be included lmao. Also censoring “bitching” is kind hard, now I can’t tell everyone about my bitching ride
What are the words in the harcoded Lemmy filter?
this is optional lol
I’m not okay with them filtering profanity, who the fuck are they to define what is or is not acceptable?
I don’t think it’s a good idea either, but it’s less egregious than filtering specific communities.
I probably agree, but frankly I find neither acceptable
The stupid thing is that all those words are only in English. No “merda”, “scheisse”, “joder”, “merde”, …
I imagine that was true for Lemmy’s similar functions in the past (referred to in this thread)
You can contribute to the codebase by offering to add them in…
They aren’t complaining that there aren’t enough filters. They’re pointing out just how stupid and futile filtering a few words is in the first place.
There may also be a misunderstanding, or perhaps this argument is only one of those that only looks smart from far away, but either way to clarify: this list isn’t truly a filter list, it’s a listing of community NAMES that will get filtered out.
For one thing, (sadly) there aren’t so many Latin-speaking instances in the Threadiverse?
And I tried to search for community names for some of the others, but did not find any? e.g. https://feddit.org/search?q=scheisse&type=Communities&listingType=All, https://feddit.org/search?q=joder&type=Communities&listingType=All&page=1&sort=TopAll, etc.
So is it really “stupid” then, to block communities that don’t even exist? ich_el would be an example of one that would actually exist, although I don’t think that one needs to be filtered out. I was saying that if there is really truly one that should be filtered, then it could be added to the list?
If someone wanted a less ah… “argumentative” subset of the Threadiverse, then I could see how filtering out “fuck_cars” would achieve that end (not that I agree with having such a listing, or in the exact contents of this one, but I do disagree that it is “stupid” as in ineffectual to have made the list in this way - it is achieving some kind of a purpose, and with people’s help that purpose could itself be changed, or if kept intact then the list enhanced to function even better than it has been doing so far).
But the “tits” filter can apply to “partits” (Catalan, means parties in English) or “partitsocialista”. And now there are no communities with those names… but what if someone in the future wants to create them?
George Carlin would be amused.
So if I started a piefed instance and wanted to host a 196 community I’d have to edit the list, but would every single other instance also have to or no?
Or you could pull it in manually. It’s just that the automated startup would not do it for you, for communities with these keywords. Nothing prevents anyone from pulling in the communities manually though.
Isn’t there a Java based Lemmy compatible thing too? I forgot what it was called but I think there is one.
They’re pretty explicit about what they don’t like when you sign up. That’s why I joined it
Each instance should be free to set their own rules. Individual instances blocking those communities is fine, but the PieFed devs hardcoding a blocklist that applies to all instances (especially one as opinionated and arbitrary as this) is absolutely not.
They… are though? Maybe I am dumb, but I do not understand why each instance setting its own rules would apply to all other instances? Say if you made your own instance, you would set your own rules, but the other instances are free to set theirs as well? Like if you want to allow communities such as “4chan”, then go ahead, but if others want to block that, then why shouldn’t they be allowed to?
Definitely agree that this issue should be made much more transparent and easier to change, like not hard-coding it.
This filter is not part of any specific instance, it’s hardcoded into PieFed’s code. That means it applies to every PieFed instance unless the instance admin explicitly patches the code to remove it.
As mentioned elsewhere, it’s just a convenience function - anytime after starting up the instance, the admins can always pull in those communities manually. Or change this part of the code beforehand. So it’s not a hard-coded “block”, just slightly less convenient for it to not automatically pull in those communities during the one-time initial setup for an instance.
But anyway you are right that this should not be a hard-coded list.
Edit: it’s also worth mentioning that the way that Lemmy does this is via a direct pull of communities from Lemmy.ml. What I am reacting to here is not so much to say that PieFed’s method is perfect, but that both suffer from flaws, and that PieFed’s is relatively benign, at least in comparison to Lemmy’s. Lemmy uses an extremely authoritarian approach whereby Lemmy.ml is the sole and invariant arbiter of what communities are allowed vs. not during that initial one-time setup, and there is no way to change that, whereas PieFed uses a list that the instance admin is capable of changing. On the spectrum of authoritarian control, PieFed’s level here is like a 1 out of 100, whereas Lemmy’s is… well, it’s still not much in this exact situation, but it’s definitely way more. Sorry for being confusing initially in the way I worded that.
deleted by creator
I presume that it was a simple misunderstanding, but in any case it has lead to some… interesting, and ultimately quite fruitful discussion, so there’s that to have enjoyed:-).
And it really shouldn’t have been hard-coded like that. A minor issue imho, and one not really a problem until now, but at least it’s already now well on its way to being resolved. In contrast, Lemmy’s own hard-coding of Lemmy.ml into the equivalent function I doubt will ever be changed, certainly not without strong reluctance (and likely along with public outcry, as before with the filter list).
One point: I would argue that opt-in vs. -out doesn’t fully apply here, as this automated convenience function will only ever be run once upon initial setup for an instance, after which the instance admin can add any communities they desire, manually (I’m not sure why OP phrased it then as needing to be “debugged”, that seems an odd term for such routine instance maintenance tasks that do not need any modification of any code at all, anywhere?). In short, it’s not actually a “block” at all, as the wording in the meme seems to me to strongly imply by using “federate”). The phrase “opt-out” usually referrs to something harsh but that isn’t all the way fully forced, but this issue of not pulling in (initially) of communities is so extremely gentle than on the spectrum it is adjacent to “opt-in” already? Still, ultimately you are probably correct, I am just not sure of the wording there, so wanted to help by offering those additional nuances.