Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea: vocabulary for moderation actions #18

Open
jfinkhaeuser opened this issue Oct 8, 2024 · 4 comments
Open

Idea: vocabulary for moderation actions #18

jfinkhaeuser opened this issue Oct 8, 2024 · 4 comments
Labels
Future Scope This issue is not currently something within scope for the taskforce

Comments

@jfinkhaeuser
Copy link

Building on the comments in #17, I see a use for vocabularies of moderation actions.

The motivation is that different fedi software makes different moderation actions available. Some have the same effect across implementations, some have similar effects, others are unique.

I would like to propose that implementations provide a vocabulary for the actions they provide. This is mostly information, not anything that can or should be acted upon. As a result, the vocabulary should have e.g. a "moderation action" purpose, define the implementation to which the action(s) apply, and provide a textual description of its effects (and side-effects).

This vocabulary could be referenced in Flag activities (#14), for example to specify what the originating instance administrator chose to do with a report upon review. While this may not translate to the receiving instance verbatim, the choice can help administrators there to determine their own actions.

In an extended scenario, it may be possible to define local policies for mapping various types of incoming actions to locally available actions, to provide better user experience in the moderation interface by pre-selecting the most likely choice of action. Such policies could also be shared e.g. amongst compatible implementations -- but these considerations are out of scope for this issue, and would warrant experience with such a system.

@ThisIsMissEm
Copy link
Collaborator

In FediMod FIRES, I refer to these as "filters", since it follows a firewall based federation model, where you can:

  • accept
  • filter
  • reject
  • ignore

when dealing with federation. For an idea of the filters I've already tried to define, see here: https://fires.fedimod.org/concepts/filters.html

@jfinkhaeuser
Copy link
Author

I think this is great; I guess the main point is having vocabularies for this that could also be implementation or admin defined!

Starting with sensible defaults is IMHO a good thing, and starting with a firewall-alike model as well.

@bumblefudge
Copy link

my understanding of the scope of both FIRES and of the swicg task force is to prototype quickly and then get feedback from users and (if any) independent or partial reimplementers, then iterate a little before "pouring cement" and finalizing a CG report. A formal vocab could be part of that report or come later, but it's a good bit of work so getting grants or inkind donations of time from t&s orgs might be needed before volunteers commit to doing it?

@ThisIsMissEm
Copy link
Collaborator

@bumblefudge I think it's also that Fediverse software is so diverse that we can't possible define all the moderation actions for all the software. At a high level, you do have those four choices: Accept, Filter, Reject, Ignore (or Drop), but beyond that it's much more dependent on individual software and their features.

e.g., Some software might support dropping media from incoming posts as a way of not ingesting adult content, but other software might not implement that.

Some software may support high-level actions like "silencing" an actor, but a moderation action such as that is incredibly poorly defined (e.g., no one can tell me exactly what that does in Mastodon, everyone leaves something out). Like wise, suspending and actor means what exactly to different software?

@ThisIsMissEm ThisIsMissEm added the Future Scope This issue is not currently something within scope for the taskforce label Oct 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Future Scope This issue is not currently something within scope for the taskforce
Projects
None yet
Development

No branches or pull requests

3 participants