From 3a39930f3d67b5b3acc7acef184f953f1c0a2027 Mon Sep 17 00:00:00 2001 From: Catalan Lover <48515417+FSG-Cat@users.noreply.github.com> Date: Mon, 25 Apr 2022 21:00:05 +0200 Subject: [PATCH 1/8] Add files via upload --- ... room type of m.policy for policy rooms.md | 63 +++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 proposals/MSCXXXX Using room type of m.policy for policy rooms.md diff --git a/proposals/MSCXXXX Using room type of m.policy for policy rooms.md b/proposals/MSCXXXX Using room type of m.policy for policy rooms.md new file mode 100644 index 00000000000..d35e565e6b4 --- /dev/null +++ b/proposals/MSCXXXX Using room type of m.policy for policy rooms.md @@ -0,0 +1,63 @@ +# MSCXXXX Using room type of m.policy for policy rooms + +## Introduction + +This simple MSC aims to make it easier for machines and people alike to be made instantly aware if a +room is a policy list. To facilitate this this MSC recommends using the already established `type` +attribute to flag rooms as policy rooms. This builds upon the precedent set by Spaces and their +`"type": "m.space"`. Adopting this for Policy rooms allows all stakeholders to instantly know if its +a Policy room or not for rooms covered by this proposal. + +For the purposes of this MSC policy lists can at times be called a policy room. This MSC does not intend +to change the name of the feature its just used to be very clear that we are talking about rooms with a +specific usecase. + +## Proposal + +This proposal is well quite simple. Allow for Policy rooms to be marked as such using the +`"type": "m.policy"`. The precedent for this comes from Spaces where they introduced this system in a +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. + +Legacy rooms in this proposal are defined as all rooms that predate this proposal and they are free to upgrade +if they desire to but they are also free to stay on their current room version and not upgrade their +room to include a type event in the creation event. All stakeholders are expected to gracefully support +interacting with legacy rooms until a future proposal changes this recommendation. + +The Author of this MSC believes that even with the problem of legacy rooms not being covered this MSC will +be useful in the future with more use of policy rooms. + + +## Potential issues + +As is covered in the proposal section this MSC has the potential issue relating to Legacy rooms. +The Author of this MSC thinks its that its an acceptable trade-off. + + +## Alternatives + +The alternative of using Peeking over fed to try to figure out if a room is a policy list has been +considered but considering that its currently considered at the time of writing to be a very in development +technology its deemed wholly unsuited for this application. The system this proposal recommends is the same +one that was used for spaces. Spaces have proven them self's in the real world and so has this system. + +## Security considerations + +None that the author is aware of at the time of writing due to the mostly informative nature of the data. +Due to that no client should trust that just because it says m.policy it is indeed a policy room the security +implications should be minimal. + +## Unstable prefix + +If you want to implement this MSC before its merged your free to use the unstable type of +`support.feline.policy.lists.msc.v1` please note that stakeholders are under no obligation to support this +unstable prefix after this MSC gets merged as of time of writing. + +## Dependencies + +The Author is not aware of any unstable MSC dependencies for this MSC. \ No newline at end of file From 32dca9f051250ec9ac2d91c27ab1bb7fb338ae83 Mon Sep 17 00:00:00 2001 From: Catalan Lover <48515417+FSG-Cat@users.noreply.github.com> Date: Mon, 25 Apr 2022 21:00:59 +0200 Subject: [PATCH 2/8] Rename MSCXXXX Using room type of m.policy for policy rooms.md to XXXX-Using-room-type-of-m.policy-for-policy-rooms.md --- ....md => XXXX-Using-room-type-of-m.policy-for-policy-rooms.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename proposals/{MSCXXXX Using room type of m.policy for policy rooms.md => XXXX-Using-room-type-of-m.policy-for-policy-rooms.md} (98%) diff --git a/proposals/MSCXXXX Using room type of m.policy for policy rooms.md b/proposals/XXXX-Using-room-type-of-m.policy-for-policy-rooms.md similarity index 98% rename from proposals/MSCXXXX Using room type of m.policy for policy rooms.md rename to proposals/XXXX-Using-room-type-of-m.policy-for-policy-rooms.md index d35e565e6b4..1c7057326a3 100644 --- a/proposals/MSCXXXX Using room type of m.policy for policy rooms.md +++ b/proposals/XXXX-Using-room-type-of-m.policy-for-policy-rooms.md @@ -60,4 +60,4 @@ unstable prefix after this MSC gets merged as of time of writing. ## Dependencies -The Author is not aware of any unstable MSC dependencies for this MSC. \ No newline at end of file +The Author is not aware of any unstable MSC dependencies for this MSC. From 4e5c46c97141439c5a39e34ef34aa3ffe94cb4b5 Mon Sep 17 00:00:00 2001 From: Catalan Lover <48515417+FSG-Cat@users.noreply.github.com> Date: Mon, 25 Apr 2022 21:01:22 +0200 Subject: [PATCH 3/8] Rename XXXX-Using-room-type-of-m.policy-for-policy-rooms.md to XXXX-using-room-type-of-m.policy-for-policy-rooms.md --- ...ms.md => XXXX-using-room-type-of-m.policy-for-policy-rooms.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename proposals/{XXXX-Using-room-type-of-m.policy-for-policy-rooms.md => XXXX-using-room-type-of-m.policy-for-policy-rooms.md} (100%) diff --git a/proposals/XXXX-Using-room-type-of-m.policy-for-policy-rooms.md b/proposals/XXXX-using-room-type-of-m.policy-for-policy-rooms.md similarity index 100% rename from proposals/XXXX-Using-room-type-of-m.policy-for-policy-rooms.md rename to proposals/XXXX-using-room-type-of-m.policy-for-policy-rooms.md From 8f3a8b4d53027f372ee5dd91b95dd2ff4487878d Mon Sep 17 00:00:00 2001 From: Catalan Lover <48515417+FSG-Cat@users.noreply.github.com> Date: Mon, 25 Apr 2022 21:09:59 +0200 Subject: [PATCH 4/8] Update and rename XXXX-using-room-type-of-m.policy-for-policy-rooms.md to 3784-using-room-type-of-m.policy-for-policy-rooms.md --- ....md => 3784-using-room-type-of-m.policy-for-policy-rooms.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename proposals/{XXXX-using-room-type-of-m.policy-for-policy-rooms.md => 3784-using-room-type-of-m.policy-for-policy-rooms.md} (96%) diff --git a/proposals/XXXX-using-room-type-of-m.policy-for-policy-rooms.md b/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md similarity index 96% rename from proposals/XXXX-using-room-type-of-m.policy-for-policy-rooms.md rename to proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md index 1c7057326a3..4640a08ea08 100644 --- a/proposals/XXXX-using-room-type-of-m.policy-for-policy-rooms.md +++ b/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md @@ -1,4 +1,4 @@ -# MSCXXXX Using room type of m.policy for policy rooms +# MSC3784 Using room type of m.policy for policy rooms ## Introduction From 8d99dcaa423e307ed7785fb1c9b624fb83854c12 Mon Sep 17 00:00:00 2001 From: Catalan Lover <48515417+FSG-Cat@users.noreply.github.com> Date: Sun, 24 Jul 2022 22:46:03 +0200 Subject: [PATCH 5/8] Improve Post merge information Added improved information about what to do after the MSC gets merged. --- .../3784-using-room-type-of-m.policy-for-policy-rooms.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md b/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md index 4640a08ea08..5c292e2d73d 100644 --- a/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md +++ b/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md @@ -55,8 +55,10 @@ implications should be minimal. ## Unstable prefix If you want to implement this MSC before its merged your free to use the unstable type of -`support.feline.policy.lists.msc.v1` please note that stakeholders are under no obligation to support this -unstable prefix after this MSC gets merged as of time of writing. +`support.feline.policy.lists.msc.v1`. + +After this MSC gets merged if a stakeholder has elected to remove its support for the unstable prefix if any +support existed or support never existed revert to Legacy room behavior for rooms that used the unstable prefix. ## Dependencies From 7278e35fb844127688d878e5ca0571fb42cf0978 Mon Sep 17 00:00:00 2001 From: Catalan Lover <48515417+FSG-Cat@users.noreply.github.com> Date: Fri, 20 Mar 2026 20:12:56 +0100 Subject: [PATCH 6/8] Apply suggestions made by Travis R. Co-authored-by: Travis Ralston --- ...-room-type-of-m.policy-for-policy-rooms.md | 73 ++++++++++--------- 1 file changed, 38 insertions(+), 35 deletions(-) diff --git a/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md b/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md index 5c292e2d73d..9bfb310b2de 100644 --- a/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md +++ b/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md @@ -2,63 +2,66 @@ ## Introduction -This simple MSC aims to make it easier for machines and people alike to be made instantly aware if a -room is a policy list. To facilitate this this MSC recommends using the already established `type` -attribute to flag rooms as policy rooms. This builds upon the precedent set by Spaces and their -`"type": "m.space"`. Adopting this for Policy rooms allows all stakeholders to instantly know if its -a Policy room or not for rooms covered by this proposal. +Matrix already has [Moderation Policy Lists](https://spec.matrix.org/v1.17/client-server-api/#moderation-policy-lists) +which describe policy recommendations through state events. In typical usage, +these policy recommendations tend to appear in dedicated rooms, though are not +required to. -For the purposes of this MSC policy lists can at times be called a policy room. This MSC does not intend -to change the name of the feature its just used to be very clear that we are talking about rooms with a -specific usecase. +Having the policy recommendations in dedicated rooms helps clients better understand +the purpose of a room, and potentially hide it if the client knows it can't do +much with that dedicated purpose. For example, a messaging client might want to +hide policy list rooms by default to avoid showing "non-conversational" rooms to +the user. -## Proposal +This proposal introduces a [room type](https://spec.matrix.org/v1.17/client-server-api/#types) +to denote such dedicated rooms. -This proposal is well quite simple. Allow for Policy rooms to be marked as such using the -`"type": "m.policy"`. The precedent for this comes from Spaces where they introduced this system in a -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. +## Proposal -Legacy rooms in this proposal are defined as all rooms that predate this proposal and they are free to upgrade -if they desire to but they are also free to stay on their current room version and not upgrade their -room to include a type event in the creation event. All stakeholders are expected to gracefully support -interacting with legacy rooms until a future proposal changes this recommendation. +Rooms dedicated to containing policy list recommendations SHOULD use a newly +defined `m.policy` room type. How clients choose to (not) handle the new type is +left as an implementation detail. -The Author of this MSC believes that even with the problem of legacy rooms not being covered this MSC will -be useful in the future with more use of policy rooms. +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 +type, and some communities might mix conversation and recommendations in the +same room (therefore not dedicating the room to recommendations). ## Potential issues -As is covered in the proposal section this MSC has the potential issue relating to Legacy rooms. -The Author of this MSC thinks its that its an acceptable trade-off. +Clients which have dedicated UX for policy rooms might not be able to apply that +UX to rooms missing the `m.policy` room type. They can try to look for recommendation +state events contained in the room, though if their dedicated UX is invasive then +it may hide conversation being had in the room. This proposal does not attempt to +make rooms without the `m.policy` room type, but still contain policy recommendations, +invoke any dedicated UX a client might have - clients can choose how/if they handle +this case. ## Alternatives -The alternative of using Peeking over fed to try to figure out if a room is a policy list has been -considered but considering that its currently considered at the time of writing to be a very in development -technology its deemed wholly unsuited for this application. The system this proposal recommends is the same -one that was used for spaces. Spaces have proven them self's in the real world and so has this system. +Peeking over federation, like in [MSC2444](https://github.com/matrix-org/matrix-spec-proposals/pull/2444), +can help clients identify rooms which contain policy list recommendation state +events. However, as identified above, this may be insufficient to properly +identify rooms *dedicated* to containing those state events. ## Security considerations -None that the author is aware of at the time of writing due to the mostly informative nature of the data. -Due to that no client should trust that just because it says m.policy it is indeed a policy room the security -implications should be minimal. +This change is largely informative and carries no direct security impact. Clients +which interpret the `m.policy` room type will need to consider security in their +implementations. For example, if hiding the rooms then notifications in those +rooms will need some consideration. ## Unstable prefix -If you want to implement this MSC before its merged your free to use the unstable type of +If you want to implement this MSC before its merged you're free to use the unstable type of `support.feline.policy.lists.msc.v1`. After this MSC gets merged if a stakeholder has elected to remove its support for the unstable prefix if any -support existed or support never existed revert to Legacy room behavior for rooms that used the unstable prefix. +Because the room type is immutable, rooms which use the unstable room type might +find themselves "unsupported" when/if implementations drop support for the unstable +type when this proposal becomes stable. ## Dependencies From 5b6fb95ecd6793a2a94191dff6e27170e42b4ad8 Mon Sep 17 00:00:00 2001 From: Catalan Lover Date: Tue, 21 Apr 2026 07:46:57 +0200 Subject: [PATCH 7/8] Fix markdown linting issues. This is a separate commit from the proper review feedback commit so that the feedback integration isnt drowned in noise. --- ...-room-type-of-m.policy-for-policy-rooms.md | 24 +++++++++---------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md b/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md index 9bfb310b2de..45940e02f0c 100644 --- a/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md +++ b/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md @@ -4,13 +4,13 @@ Matrix already has [Moderation Policy Lists](https://spec.matrix.org/v1.17/client-server-api/#moderation-policy-lists) which describe policy recommendations through state events. In typical usage, -these policy recommendations tend to appear in dedicated rooms, though are not -required to. +these policy recommendations tend to appear in dedicated rooms, though are not +required to. Having the policy recommendations in dedicated rooms helps clients better understand the purpose of a room, and potentially hide it if the client knows it can't do much with that dedicated purpose. For example, a messaging client might want to -hide policy list rooms by default to avoid showing "non-conversational" rooms to +hide policy list rooms by default to avoid showing "non-conversational" rooms to the user. This proposal introduces a [room type](https://spec.matrix.org/v1.17/client-server-api/#types) @@ -20,14 +20,13 @@ to denote such dedicated rooms. Rooms dedicated to containing policy list recommendations SHOULD use a newly defined `m.policy` room type. How clients choose to (not) handle the new type is -left as an implementation detail. +left as an implementation detail. -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 -type, and some communities might mix conversation and recommendations in the +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 +type, and some communities might mix conversation and recommendations in the same room (therefore not dedicating the room to recommendations). - ## Potential issues Clients which have dedicated UX for policy rooms might not be able to apply that @@ -38,7 +37,6 @@ make rooms without the `m.policy` room type, but still contain policy recommenda invoke any dedicated UX a client might have - clients can choose how/if they handle this case. - ## Alternatives Peeking over federation, like in [MSC2444](https://github.com/matrix-org/matrix-spec-proposals/pull/2444), @@ -48,15 +46,15 @@ identify rooms *dedicated* to containing those state events. ## Security considerations -This change is largely informative and carries no direct security impact. Clients +This change is largely informative and carries no direct security impact. Clients which interpret the `m.policy` room type will need to consider security in their -implementations. For example, if hiding the rooms then notifications in those +implementations. For example, if hiding the rooms then notifications in those rooms will need some consideration. ## Unstable prefix -If you want to implement this MSC before its merged you're free to use the unstable type of -`support.feline.policy.lists.msc.v1`. +If you want to implement this MSC before its merged you're free to use the unstable type of +`support.feline.policy.lists.msc.v1`. After this MSC gets merged if a stakeholder has elected to remove its support for the unstable prefix if any Because the room type is immutable, rooms which use the unstable room type might From 49a15d9a2bfa29c3866f851a7424b99a52c8cdc6 Mon Sep 17 00:00:00 2001 From: Catalan Lover Date: Tue, 21 Apr 2026 07:49:10 +0200 Subject: [PATCH 8/8] Integrate review feedback from Gnuxie Co-authored-by: Gnuxie --- .../3784-using-room-type-of-m.policy-for-policy-rooms.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md b/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md index 45940e02f0c..eaa0c991f1d 100644 --- a/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md +++ b/proposals/3784-using-room-type-of-m.policy-for-policy-rooms.md @@ -22,10 +22,9 @@ Rooms dedicated to containing policy list recommendations SHOULD use a newly defined `m.policy` room type. How clients choose to (not) handle the new type is left as an implementation detail. -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 -type, and some communities might mix conversation and recommendations in the -same room (therefore not dedicating the room to recommendations). +Where the `m.policy` room type is used, conversation is not expected. +Clients SHOULD note that moderation policies can appear in rooms without the `m.policy` type, +where conversation could be present. ## Potential issues