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!

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.

Does Nheko use it besides just declaring the constant?

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.

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

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.

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.

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.

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.

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.

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.

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

This is very confusing and I don't understand what it is recommending. I understand at a protocol level you can send whatever you want into room, but what's the expected/recommended behavior? Is this like a space that it isn't expected to have conversation or is it expected?

@mscbot concern Confusing behavior around whether or not conversation occurs in policy rooms.

Policies live in a bit of a grey area there its essentially communicating. 99% of policy lists work just as spaces usually do. Pure Policies no conversations just like how Spaces usually are exclusively spaces nothing else.

Its just someone might decide to mix policies into conversation for some reason. Be that the original idea that Travis talked about in https://github.com/matrix-org/matrix-spec-proposals/pull/3784/changes#r858892009 or some other reason.

We are also trying to address what was refered to as the legacy problem originally. Aka what to do with policy lists like CME that predate the MSC or Matrix.org COC. Both these lists predate the MSC and predate the mjolnir support for the MSC that was later inherited by Draupnir and implemented by Meowlnir.

Some of this comment may potentially have to make it into the file in a more refined form ofc. Just not sure what if anything from this comment needs to land inside of the MSC it self.

Conversation is not mixed in policy rooms. The highlighted text is attempting to clarify that moderation policies can exist in rooms without the m.policy type.

The current text is confusing. I would make it clear that m.policy rooms are not expected to have conversation.

Maybe use a paragraph break to talk about legacy policy rooms and that nothing in this MSC applies to them?

This change would not reflect the second more important reason why the type is lacking. Lists that predate the type. Other than that i think its a good suggestion.

I feel the suggestion implies the lack of type sufficiently. This will need line wrapping, but is otherwise great - thank you!

@clokep @Johennes - would this resolve your concerns around the MSC not spelling it out?

Yeah, I think that is clearer.

Yes, thanks.