MSC3784: Using room type of m.policy for policy rooms

[FSG-Cat]

Rendered

This simple MSC aims to help stakeholders know if its likely to be a room containing a policy list or not.

Signed-off-by: Catalan Lover catalanlover@protonmail.com

---

SCT Stuff

MSC checklist

FCP tickyboxes

[deepbluev7]

To expand on this a bit, I really need something like this. Without this you run into a bootstrapping issue. Is this room supposed to be a policy room before the first policy is sent?

Without a room type you need to inspect the full room state to look for policy rules before you switch to the policy editor design. Slash commands can't warn the user properly that they are sending the rule into the wrong room.

So yes, I very much need this to provide a nice experience in my client. I can somewhat paper over it using account data, but it is not great. Everywhere we are told rooms are cheap. So far no rooms send policy rules into rooms you can send messages in. Most moderation tools even make it impossible to message in policy rooms, since that could possibly break the policy room when you actually need it to fight spam.

Thank you for writing this MSC!

[FSG-Cat]

Making this thread to track Implementation status outside of the PR descript.

Implementation Tracking

Mjolnir as of da08432 and that commit is included in Release 1.6.0. Mjolnir implementation at time of writing only includes that it creates rooms for policy lists with the type.
Nheko in mtxclient has added initial support to recognise it in 4bd39bce. Further progres unknown at time of writing.

[clokep]

Does Nheko use it besides just declaring the constant?

[FSG-Cat]

Policy Editing that utilises MSC3784 to aid in detecting if a room is a policy list is implemented in RMU. Version that implemented first is unknown but current Version as of writing relies on this as one of its 2 detection methods. It also supports legacy detection.

[TheArcaneBrony]

https://mru.rory.gay/PolicyLists is the particular page in RMU that uses this MSC to find policy rooms. I'm not sure whether it has legacy detection enabled or not, but legacy detection here was implemented by checking for the Mjolnir shortcode state event. It does not show rooms that happen to have policy events, as querying /sync or /state for rooms is very expensive, especially compared to cherry picking 2 events.

(Oops, I still have to get rid of the "Create policy list" popup being there by default, which also uses the MSC's unstable type on room creation, additionally I've just uncovered a crash related to fetching room names... That's for the tomorrow pile).

[turt2live]

My general feeling is this is something we should have in the spec to identify rooms dedicated to containing policy list recommendations. There might still be some rooms which want to mix recommendations with conversation - those rooms wouldn't use this type and might not get the benefits of dedicated UX from a client, but that's okay.

I've given this MSC a sizable editorial review. It's not my intention to completely change how this proposal works, so if that's happened then please correct me 😅. The editorial comments here reflect that ~650 MSCs have been opened in the time since this one was, and that modern MSCs are typically held to a different standard than older ones. I've also tried to make some areas a bit more clear & concise, as would happen in normal review.

My approval denotes that the MSC is ready for proposed-FCP with the edits (or something reasonably close). The listed implementations appear to satisfy the requirements we'd have for this proposal.

[clokep]

Small quibble that I wouldn't block this MSC on, but should we use m.moderation_policy to be a bit more descriptive? I could think of multiple types of policies.

[TheArcaneBrony]

Shouldn't the policy server MSC then also be updated to use m.moderation_policy as an event type rather than m.policy or whatever the final variant was?

[FSG-Cat]

Im not married to any particular final name for the room type. I was just copying the precedent set by spaces at the time of writing originally.

So i will take this to the saftey guild and ask them for input on what the name should be.

[clokep]

Maybe we're already using this term, and that's ok. Thanks for providing the context on why this was chosen. It just stuck out to me as really vague.

Would be curious for other SCT input here.

[richvdh]

I feel like @turt2live would have more context on whether this is a sensible name or not. I agree that m.policy feels a bit vague.

[turt2live]

As the person who advocated for m.room.policy to enter the spec as-is, I'm not sure my opinion is super reliable 😅. I'm personally fine with m.policy as a room type because it's "a room containing a policy". The 'policy' happens to be expressed with primarily ban rules, but in future could be more than that (anonymous reputation data, shades of gray policy definitions to determine on-topic-ness, etc).

I'm also generally of the opinion that calling it a "moderation policy list" in the spec is wrong, but I'm not concerned enough to actually raise a bug fix PR or issue for it. The use case is to communicate general policy data, not specific to moderation. This could be a security policy, entrance policy, community volunteer policy, etc.

[FSG-Cat]

A practical use case that exists today where policies are not "moderation policies" would actually be the Access controls for Mjolnir and Draupnir Appservice mode. While they are broken in Draupnir currently they work in Mjolnir as far as i know because it used to work in Draupnir and we did not touch that part of the codebase to my knowledge in that way. (I should note we use the moderation policy recommendations in this context but thats also more of a easiest path forward type of situation i would argue. But thats also only for the disallow policy the allow policy is a custom one in the org.matrix namespace.)

In this case the policies simply control if your bot is allowed to start or not and if your doing Appservice hosting as a service you can easily hook this into a subscription management system. Be that paid or free subscriptions.

Point im trying to make is that we have a concrete already in the wild use case where policies are not strict moderation but something a bit different and we have lots of exploration wanting to extend this system further.

Personally i would say that room sub typing also comes into play here as if we had sub typing then definitively could argue if moderation should be its own subtype and the flagship subtype for the first MSC to try to define a policy subtype due to its clear and proven track record.

Now the fact that the appservice admin room is where Mjolnir and Draupnir stores the policy list is a design choice that as far as i understand exists out of convenience not any actual necessity. Appservice mode was a small beta project that had beta issues that make complete sense in context. The admin room having the policies is one of them and is a choice that i personally would argue for moving away from if one wants to modernize the mode (and is something i may personally look at in the future inside of the Draupnir project) as the room type benefits are quite large for specialized tools like RMU and any other matrix client that wants to implement policy manipulation.

[mscbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[turt2live]

Spec PR: matrix-org/matrix-spec#2411

[turt2live]

Merged 🎉