MSC3784: Using room type of m.policy for policy rooms
#3784
Conversation
…X-Using-room-type-of-m.policy-for-policy-rooms.md
…sing-room-type-of-m.policy-for-policy-rooms.md
…d to 3784-using-room-type-of-m.policy-for-policy-rooms.md
uhoreg
added
proposal-in-review
proposal
| @@ -0,0 +1,63 @@ | |||
| # MSC3784 Using room type of m.policy for policy rooms | |||
There was a problem hiding this comment.
The whole point of policy rules was that they wouldn't get a room type, because there's zero practical reason to do so. In fact, it was originally intended that Matrix HQ itself would be the "ban list" plus regular chat, making it easy for others to subscribe to the list and see what was going on. The only reason we didn't end up doing that was because we wanted to keep the rules out of the main chat during development, and never migrated away.
Room types are generally used if the room can't practically hold information for other purposes, like spaces being practically unusable as a chatroom or profiles being useless as spaces. Policies are just arbitrary state events though and can live anywhere. It's very much a feature that rooms can contain multiple kinds of information when possible, which means a space which is also a policy room (for example).
There was a problem hiding this comment.
Well the way i personally see them used is as dedicated rooms mostly. This proposal aims to help that usecase but is not mutually exclusive with the usecases you mentioned in my head. Yes its probably a bit of a misuse of the type attribute in the sense that policy lists can contain other information unlike the other examples.
There was a problem hiding this comment.
because there's zero practical reason to do so
@turt2live You're being a bit too certain about this 😞.
, it was originally intended that Matrix HQ itself would be the "ban list" plus regular chat, making it easy for others to subscribe to the list and see what was going on.
Original intent is fair to raise for context, but this isn't how policies are used, and it would be bad to use Matrix HQ this way. Not only is HQ a difficult room to query room state from because of the number of state events it has, but it's just not an appropriate place for them.
and see what was going on
Which would also be difficult because policy changes would be mixed with the chat timeline right?
Policies are just arbitrary state events though and can live anywhere. It's very much a feature that rooms can contain multiple kinds of information when possible, which means a space which is also a policy room (for example).
This isn't how they are used though, even matrix.org has dedicated rooms with chat disabled.
It makes a lot of sense to show these dedicated rooms differently in clients so that people can browse the rules and admins can edit them.
There was a problem hiding this comment.
Sounds like this makes a good argument and this info just needs to make its way back into the MSC of why the current status quo isn't enough (or just isn't used). It is usually good to reference historical context too.
| limited capacity. This proposal expands this system to help all stakeholders quickly identify | ||
| policy rooms in a machine compatible way that is computationally cheap. It has additional benefits like | ||
| allowing clients that are capable of editing policy to display editing tools for policy rooms when they | ||
| detect that a room is a policy room using this mechanic. For machine interaction with policy rooms this | ||
| proposal supplies a very fast way to tell if a room is definitively supposed to be a policy room or if | ||
| the user might have supplied a legacy room or typed in the wrong room ID / alias depending on how things | ||
| are configured. |
There was a problem hiding this comment.
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!
Added improved information about what to do after the MSC gets merged.
matrix-org/matrix-spec-proposals#3784 This was extracted from the appservice mjolnir work to reduce review burden.
matrix-org/matrix-spec-proposals#3784 This was extracted from the appservice mjolnir work to reduce review burden.
matrix-org/matrix-spec-proposals#3784 This was extracted from the appservice mjolnir work to reduce review burden.
matrix-org/matrix-spec-proposals#3784 This was extracted from the appservice mjolnir work to reduce review burden.
| @@ -0,0 +1,65 @@ | |||
| # MSC3784 Using room type of m.policy for policy rooms | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Does Nheko use it besides just declaring the constant?
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