Granular moderation through Room Categories

[ShadowJonathan]

Is your feature request related to a problem? Please describe.

Currently it is hard to moderate a wide set of rooms, as some of them would require different moderation approaches, some more lenient ACLs, some more strict, etc.

This becomes a problem when mjolnir applies ACL and policy to all rooms equally, and similarly with protections.

Describe the solution you'd like.

Have Mjolnir have the concept of room "categories" (or alternatively called "subsets") which;

• Each category can apply to a different range of rooms. For the sake of simplicity, these ranges are non-overlapping, a room can belong to either 1 category, or none (non-protected rooms).
• Each category can source from different policy lists, allowing granular tuning of which rooms are moderated by what lists.
• Optionally, depending on how hard this is to implement, each category can also have its own set of protections running, optionally also with different configurations.

---

From the mjolnir room, a way i suggested to implement this would be to have Spaces be an implicit categorization. But for the sake of simplicity, this will not apply here, as the above calls for a non-overlapping (and thus non-conflicting) set of categories.

[Gnuxie]

I think it makes a lot of sense to use Spaces as categories because that is the tool Matrix has given us to do this. It's also a concept that people who use Matrix will already have to understand. It then makes a lot of sense to try make Mjolnir "Space aware" in the way it applies rules. It should be quite simple to use the Space hierarchy to determine what rules/ACL/bans will be applied and then use that later to scope Mjolnir specific things like "which protections are enabled". I think this approach can be broken down into a few parts

1. Add the concept of spaces to Mjolnir

   • Allow protecting "all of the rooms within a space", which nicely unloads the UX for adding/removing protected rooms to clients :smirk_cat:

2. Implement space specific policy following

   • Use the hierarchy of spaces to resolve conflicts, it only gets more strict as you go down.
   • Consider whether we want to have policies direct in spaces or not or use https://github.com/matrix-org/matrix-spec-proposals/pull/3784, leaning towards the latter because I'm worried about how many clicks it would take to bring up the policy view.

3. implement a view in a client to view/search change the policies that are in effect in a room (follow links to the rooms they come from when you are following a list). Even more UX gets offloaded from Mjolnir commands into clients. Shoutout to https://github.com/MTRNord/matrix-moderation-widget

4. Add in Mjolnir support for propagating room bans to their parent spaces

5. Add in Mjolnir support for specific protection settings per space.

[ShadowJonathan]

Thank you for taking the time to illustrate the Spaces principle, I wasn't keen on adding it directly for some reasons;

• What would be the algorithm to resolve room policy if a room was in two spaces at once? Policy lists are additive, but protection settings are not.
  • Would, for the latter, this maybe be resolved by an explicit m.space.parent selection? This'd require all rooms like that to have parent selections, with not-so-clear behavior when it doesn't have one.
• I don't know yet how policy list recommendations are going to mesh with all this when multiple of them are telling different recommendations. This is not a problem limited to spaces, but potentially, a space's "place" in the hierarchy might also become an influencing factor as to what policy might get applied. (Lets say that the recommendation for the main rooms is "mute" or something, but a recommendation from a policy list watched directly by the stricter space is "ban", this might be useful, but a robust algorithm needs to be thought of on how to implement this)

[Gnuxie]

Would, for the latter, this maybe be resolved by an explicit m.space.parent selection?

That's a good point, I was assuming that would be normal but that is probably not be the case

[ShadowJonathan]

It's not common, so I'm not entirely sure if we should rely on it, or have mjolnir ask to fix it itself.

[Gnuxie]

I think the way we avoid conflicts between spaces sharing a child is just to make the conflict obvious and deal with it by imagining there are two different mjolnirs in the same room with different lists. Conflict resolution can be an after thought so long as they know there is one and why (the hierarchies causing the conflict).

[ShadowJonathan]

I believe that would make internal representation easier, and also make this quite explicit, but it'd still possibly have unforeseen consequences.

We should maybe lookout for potentially self-triggering behaviour, and make sure the "double mjolnir" approach doesnt trigger it.