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.

[turt2live]

MSCs proposed for Final Comment Period (FCP) should meet the requirements outlined in the checklist prior to being accepted into the spec. This checklist is a bit long, but aims to reduce the number of follow-on MSCs after a feature lands.

SCT members: please check off things you check for, and raise a concern against FCP if the checklist is incomplete. If an item doesn't apply, prefer to check it rather than remove it. Unchecking items is encouraged where applicable.

MSC authors: feel free to ask in a thread on your MSC or in the#matrix-spec:matrix.org room for clarification of any of these points.

• Are appropriate implementation(s) specified in the MSC’s PR description?
• Are all MSCs that this MSC depends on already accepted?
• For each new endpoint that is introduced:
  • Have authentication requirements been specified?
  • Have rate-limiting requirements been specified?
  • Have guest access requirements been specified?
  • Are error responses specified?
    • Does each error case have a specified errcode (e.g. M_FORBIDDEN) and HTTP status code?
      • If a new errcode is introduced, is it clear that it is new?
• Will the MSC require a new room version, and if so, has that been made clear?
  • Is the reason for a new room version clearly stated? For example, modifying the set of redacted fields changes how event IDs are calculated, thus requiring a new room version.
• Are backwards-compatibility concerns appropriately addressed?
• Are the endpoint conventions honoured?
  • Do HTTP endpoints use_underscores_like_this?
  • Will the endpoint return unbounded data? If so, has pagination been considered?
  • If the endpoint utilises pagination, is it consistent with the appendices?
• An introduction exists and clearly outlines the problem being solved. Ideally, the first paragraph should be understandable by a non-technical audience.
• All outstanding threads are resolved
  • All feedback is incorporated into the proposal text itself, either as a fix or noted as an alternative
• While the exact sections do not need to be present, the details implied by the proposal template are covered. Namely:
  • Introduction
  • Proposal text
  • Potential issues
  • Alternatives
  • Dependencies
• Stable identifiers are used throughout the proposal, except for the unstable prefix section
  • Unstable prefixes consider the awkward accepted-but-not-merged state
  • Chosen unstable prefixes do not pollute any global namespace (use “org.matrix.mscXXXX”, not “org.matrix”).
• Changes have applicable Sign Off from all authors/editors/contributors
• There is a dedicated "Security Considerations" section which detail any possible attacks/vulnerabilities this proposal may introduce, even if this is "None.". See RFC3552 for things to think about, but in particular pay attention to the OWASP Top Ten.

[turt2live]

@mscbot fcp merge

[mscbot]

Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:

• @clokep
• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @tulir
• @erikjohnston
• @KitsuneRal

Concerns:

• Confusing behavior around whether or not conversation occurs in policy rooms.

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[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.