this post was submitted on 05 Sep 2023
527 points (95.8% liked)
Fediverse
28489 readers
613 users here now
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, 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), Search Lemmy
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
First of all I want to sort of apologize, my comment was a lot angrier than initially intended because first lemmy erased my first draft (which was not nearly as aggressive) and then my hunger caught up with me. Not meant as an excuse for it but rather an explanation that the anger wasn't intended.
Currently ther e is an option to block NSFW entirely, under the tag system that functionality has to be preserved, therefore at the very least an option to completely block the nsfw type tag will be implemented. I did not think mentioning that no feature degradation should occur was necessary, given that it caused some confusion I'll probably go back and write the implicit parts out.
As quoted by yourself later on:
Again I did not think I needed to explicitly state that this easier filtering would be done via the type because I thought it was implicitly clear from the context.
Same reason as above but this time even more fundamental: I'm not gonna rechew programming basics in a document aimed at other programmers. The ability to filter by name is given since the thing has its own json field.
They would not and that is indeed a minor issue with the entire thing. I don't really think that will be a big issue since tag filtering will likely be done via type + name and not via id as well as tags being coalesced due to federation. Aside from that the default settings of tags should prevent accidental viewing of content (as mentioned in the RFC both NSFW and CW tags will be blurred by default, meaning until users can select to not blur a cw tag themselves)
It's fine, what I think I should include in the RFC is the possibility to include more tag types should real use of tags show that they would be beneficial. It's a lot easier to add categories there than remove them later on which is why I want to keep the initial amount of types to the absolute minimum needed. In this case that's 2+1 since NSFW needs to be split off from cw for feature parity with the current NSFW system.
Programmatically speaking there is absolutely no difference between filtering in and filtering out, which is why I don't think splitting CWs and Tags makes sense. From what I can tell the other Fediverse Platforms handle this in a very similar manner. It also assumes that everyone only wants to filter out CWs, but that is not true. Some people want to filter out porn, others want explicitly only porn in their feed. Some users might not want to see gore or spoilers while others like to read through those things. So in the end there is not even a line between clear "filter-in" and "filter-out" labels for posts.
Edit: forgot to include but to clear up another misunderstanding: RFC means Request for Change, comments are welcome but it is primarily a document aimed at people already somewhat familiar with the debate to find any major issues with the proposal. I wrote the RFC only after my basic idea received approval by the people already involved in the GitHub discussion.
Okay, thanks for replying. Your points make sense, especially
this one. I also wasn't aware that the document was a part of a larger discussion and sorry about the rfc meaning confusion😅
Hope you could have a meal :)
Yeah I had a pizza before/while typing the 2nd comment.
Again sorry for the overly aggressive tone of the first one.