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.

[Johennes]

SHOULD feels slightly odd to me here because consumers have complete freedom in how they handle (or don't handle) policy recommendations. There is nothing normative here and I think this should rather be a remark.

Suggested change

	Consumers of policy lists SHOULD note that recommendations can still appear
	outside of `m.policy` rooms. Existing rooms probably won't have the new room
	Consumers of policy lists should note that recommendations can still appear
	outside of `m.policy` rooms. Existing rooms probably won't have the new room

[FSG-Cat]

This part may be a bit wierdly worded due to being translated from the old legacy rooms handling that the MSC defined. And yes a strong but optional world like SHOULD is correct to the intent.

The intended way this is meant to be handled is that policy manipulation tooling should allow you to override the automatic detection the room type gives you and instead use manual detection. Be that temporary as in not persisted or persisted personal overrides stored via implementation specific means.

Secondary detection measures like checking for shortcode is also allowed but as @TheArcaneBrony can testify to its cludgy compared to pure room type detection.

[turt2live]

I believe this would be resolved by #3784 (comment)

[Johennes]

Missing notifications feels like a potential issue rather than a security consideration to me. Should there be a note in the proposal section that m.policy rooms can still include normal conversation? We already have the complementary remark there that regular rooms can still contain policy lists.

[turt2live]

Hidden/unobtainable notifications are occasionally considered a security concern in an implementation because of the disruption they cause. That's the only reason to mention it here.

m.policy rooms should not contain conversation, per the MSC.

[Johennes]

m.policy rooms should not contain conversation, per the MSC.

The proposal doesn't seem to explicitly say that. It speaks of "rooms dedicated to containing policy list recommendations" which may intend to say just that but this isn't very clear in my opinion.

[FSG-Cat]

There is no enforcement what so ever so your client should NOT trust that nobody in the long history of doing things like this for the lulz on matrix, decides to make a policy list with room type and short code and all just to have it as their offtopic lounge style room.

Like i have a long history of seeing people intentionally toy with edge cases like this on matrix and so does several SCT members.

Enforcement would require a room version and that is unneeded complexity. Policy lists should always already be created via specialised tools that will prevent these types of situations via strategic configuration of the powerlevels for non creators. This is because normal clients cant set room types for non space rooms. Only specialised clients or power user / developer clients will have the ability to fall into this trap. And when your using a client that intentionally lets you use the full power of matrix and has no guardrails against footguns you are on your own.

Does MSC1772 explicitly define that conversation can not exist in a space as far as auth rules are concerned? I refer to the Spaces MSC for one simple reason. It should already have debated to death this concern as this MSC is essentially the same type of MSC just for policy lists instead of introducing the concept of spaces and room types.

[turt2live]

Spaces left whether a conversation can happen in the room as an implementation detail because it was theorized as possibly useful.

[turt2live]

I believe this may be mostly/all resolved by #3784 (comment)

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