From 6f47b528fd65715b59328ab5f10f055a0688be03 Mon Sep 17 00:00:00 2001 From: Catalan Lover <48515417+FSG-Cat@users.noreply.github.com> Date: Sun, 2 Oct 2022 15:06:13 +0200 Subject: [PATCH 01/11] Initial Commit for Membership based mutes --- proposals/MSCXXXX Membership based mutes.md | 77 +++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 proposals/MSCXXXX Membership based mutes.md diff --git a/proposals/MSCXXXX Membership based mutes.md b/proposals/MSCXXXX Membership based mutes.md new file mode 100644 index 000000000..caf0510d5 --- /dev/null +++ b/proposals/MSCXXXX Membership based mutes.md @@ -0,0 +1,77 @@ +# MSC0000: Membership based mutes WORKING TITLE + +## Introduction + +As covered in in MSC_POLICY_MUTE currently in matrix mutes are done via powerlevel manipulation. +This MSC has the simple purpose of defining a path forward that alleviates this problem. Yes it does +require a room version bump but this MSC will explain why this is an acceptable compromise. + +To achieve Mutes via membership a new membership state is proposed of `muted`. It would allow you to +exclusively send EDUs and no PDUs. + +## Proposal + +This proposal defines the `muted` membership type. If a user has this membership type in a room they +are restricted to exclusively sending the read marker EDUs and nothing more. + +The legal transitions for the `muted` membership type based on Room version 10 would be +`join` -> `muted` -> `ban`,`join` + +When a users membership is `muted` they may leave the room by setting their own membership to `ban` +this transition ignores power levels and instead behaves as if it was a leave. But if the person tries to +re-join the room they will be banned the same way as anyone else. The reason for going this way is simple. +It preserves your ability to leave a room while your muted but you cant return without the moderators of the +room desiring you to have the ability to return. + +This also solves the issue of forcing implementations to break the matrix tradition and evaluate not just +the previous membership state but 2 membership states back to determine if its legal or not that would have been +required to enable leaves. + +An exception to the earlier mentioned restriction that you cant send PDUs and EDUs except read markers +is that you can send a membership event that changes your membership from `mute` to `ban`. + +## Potential issues + +_Not all proposals are perfect. Sometimes there's a known disadvantage to implementing the proposal, +and they should be documented here. There should be some explanation for why the disadvantage is +acceptable, however - just like in this example._ + +Someone is going to have to spend the time to figure out what the template should actually have in it. +It could be a document with just a few headers or a supplementary document to the process explanation, +however more detail should be included. A template that actually proposes something should be considered +because it not only gives an opportunity to show what a basic proposal looks like, it also means that +explanations for each section can be described. Spending the time to work out the content of the template +is beneficial and not considered a significant problem because it will lead to a document that everyone +can follow. + +## Alternatives + +The alternative of staying with our current Mutes as PL way has been dismissed as undesirable due to the +scaling issues. And also for the fact that it makes state resolution complexity grow at a faster rate +due to that powerlevels have to all be resolved always. + +Going the path of RBAC or another powerlevels overhaul was also dismissed because this MSC intends to in +a perfect world be able to be implemented quite quickly in a vacuum that is not tied to any other MSC. + +## Security considerations + +The `muted` membership type is going to be yet another thing that you can mess up implementing and that is +recognised as an ok. The authors of this MSC believes that is an acceptable compromise since we avoid +the PL churn of current mute implementations. We also believe that the potential issue of being trapped in +rooms is mitigated by making self bans an option to mitigate the potential to bypass a mute fully by leaving +the room. + +## Unstable prefix + +_If a proposal is implemented before it is included in the spec, then implementers must ensure that the +implementation is compatible with the final version that lands in the spec. This generally means that +experimental implementations should use `/unstable` endpoints, and use vendor prefixes where necessary. +For more information, see [MSC2324](https://github.com/matrix-org/matrix-doc/pull/2324). This section +should be used to document things such as what endpoints and names are being used while the feature is +in development, the name of the unstable feature flag to use to detect support for the feature, or what +migration steps are needed to switch to newer versions of the proposal._ + +## Dependencies + +This MSC builds on MSCxxxx, MSCyyyy and MSCzzzz (which at the time of writing have not yet been accepted +into the spec). \ No newline at end of file From 38670b9a14c2b2ff45227ef5d21749d1fc5cc0cc Mon Sep 17 00:00:00 2001 From: Catalan Lover Date: Wed, 12 Oct 2022 16:11:00 +0200 Subject: [PATCH 02/11] Flesh out potential issues section and minor tweaks. --- proposals/MSCXXXX Membership based mutes.md | 64 +++++++++++---------- 1 file changed, 35 insertions(+), 29 deletions(-) diff --git a/proposals/MSCXXXX Membership based mutes.md b/proposals/MSCXXXX Membership based mutes.md index caf0510d5..52f65c572 100644 --- a/proposals/MSCXXXX Membership based mutes.md +++ b/proposals/MSCXXXX Membership based mutes.md @@ -6,43 +6,50 @@ As covered in in MSC_POLICY_MUTE currently in matrix mutes are done via powerlev This MSC has the simple purpose of defining a path forward that alleviates this problem. Yes it does require a room version bump but this MSC will explain why this is an acceptable compromise. -To achieve Mutes via membership a new membership state is proposed of `muted`. It would allow you to +To achieve Mutes via membership a new membership state is proposed of `mute`. It would allow you to exclusively send EDUs and no PDUs. ## Proposal -This proposal defines the `muted` membership type. If a user has this membership type in a room they -are restricted to exclusively sending the read marker EDUs and nothing more. +This proposal defines the `mute` membership type. If a user has this membership type in a room they +are restricted to exclusively sending the read marker EDUs and nothing more except leaving via setting +their membership to `ban` as defined later. -The legal transitions for the `muted` membership type based on Room version 10 would be -`join` -> `muted` -> `ban`,`join` +The legal transitions for the `mute` membership type based on Room version 10 would be +`join` -> `mute` -> `ban`, `join`, `leave`(Exclusively via kick) -When a users membership is `muted` they may leave the room by setting their own membership to `ban` +When a users membership is `mute` they may leave the room by setting their own membership to `ban` this transition ignores power levels and instead behaves as if it was a leave. But if the person tries to -re-join the room they will be banned the same way as anyone else. The reason for going this way is simple. -It preserves your ability to leave a room while your muted but you cant return without the moderators of the -room desiring you to have the ability to return. +re-join the room they will be banned the same way they would be if someone else sent a valid ban. +The reason for going this way is simple. It preserves your ability to leave a room while your muted +but you cant return without the moderators of the room desiring you to have the ability to return. This also solves the issue of forcing implementations to break the matrix tradition and evaluate not just the previous membership state but 2 membership states back to determine if its legal or not that would have been required to enable leaves. -An exception to the earlier mentioned restriction that you cant send PDUs and EDUs except read markers -is that you can send a membership event that changes your membership from `mute` to `ban`. +### Authorisation rules. + +To be written. Contributions welcome. ## Potential issues -_Not all proposals are perfect. Sometimes there's a known disadvantage to implementing the proposal, -and they should be documented here. There should be some explanation for why the disadvantage is -acceptable, however - just like in this example._ +On the potential issue that this MSC requires rooms that want to employ it to be created after the room version +its included in becomes default or their homeserver makes it default or they manually select it for an upgrade is +deemed acceptable. The reason this is deemed acceptable is because as has been made clear in discussions with +community moderation teams for multiple communities not all communities want to use mutes in their toolkit and therefore +not all communities will feel the need to upgrade their room version to gain access to this feature. + +Room version upgrades them self's are being worked upon making more smooth. There is work in the area of deleting state +for example that requires better room version upgrade mechanics. There is also history importing work being done as +another avenue of lessening the impact of room version upgrades in the future. -Someone is going to have to spend the time to figure out what the template should actually have in it. -It could be a document with just a few headers or a supplementary document to the process explanation, -however more detail should be included. A template that actually proposes something should be considered -because it not only gives an opportunity to show what a basic proposal looks like, it also means that -explanations for each section can be described. Spending the time to work out the content of the template -is beneficial and not considered a significant problem because it will lead to a document that everyone -can follow. +The authors of this MSC believes that communities that desire to use this MSC to its full potential are perfectly happy +to accept the compromises involved in a room version bump. This MSCs purpose can be achieved via powerlevels +in earlier room versions. This comes at the cost of a skyrocketing state resolution complexity but this is always +an option for communities that don't want to upgrade their room version or if this MSC fails. + +The authors of this MSC are not aware of any other potential issues that have not been covered elsewhere in this MSC. ## Alternatives @@ -55,7 +62,7 @@ a perfect world be able to be implemented quite quickly in a vacuum that is not ## Security considerations -The `muted` membership type is going to be yet another thing that you can mess up implementing and that is +The `mute` membership type is going to be yet another thing that you can mess up implementing and that is recognised as an ok. The authors of this MSC believes that is an acceptable compromise since we avoid the PL churn of current mute implementations. We also believe that the potential issue of being trapped in rooms is mitigated by making self bans an option to mitigate the potential to bypass a mute fully by leaving @@ -63,13 +70,12 @@ the room. ## Unstable prefix -_If a proposal is implemented before it is included in the spec, then implementers must ensure that the -implementation is compatible with the final version that lands in the spec. This generally means that -experimental implementations should use `/unstable` endpoints, and use vendor prefixes where necessary. -For more information, see [MSC2324](https://github.com/matrix-org/matrix-doc/pull/2324). This section -should be used to document things such as what endpoints and names are being used while the feature is -in development, the name of the unstable feature flag to use to detect support for the feature, or what -migration steps are needed to switch to newer versions of the proposal._ +This MSC is not recommended to be implemented before Authorisation rules are properly specified but if implemented. +Please use the version string of `support.feline.mute.mscAAAA.v0` + +Once Authorisation rules are specified its expected that the unstable version after that is v1. This is because the +pre authorisation rules properly written down version cant be trusted to interoperate and this is why its NOT recommended +to implement a version that is based on this MSC before that section is written. ## Dependencies From 78a9b34e82cf57be11095ccb10c02f72291b084b Mon Sep 17 00:00:00 2001 From: Catalan Lover <48515417+FSG-Cat@users.noreply.github.com> Date: Thu, 13 Oct 2022 16:56:20 +0200 Subject: [PATCH 03/11] Change file name to pre submission name --- ...Membership based mutes.md => XXXX-membership-based-mutes.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename proposals/{MSCXXXX Membership based mutes.md => XXXX-membership-based-mutes.md} (97%) diff --git a/proposals/MSCXXXX Membership based mutes.md b/proposals/XXXX-membership-based-mutes.md similarity index 97% rename from proposals/MSCXXXX Membership based mutes.md rename to proposals/XXXX-membership-based-mutes.md index 52f65c572..928d82679 100644 --- a/proposals/MSCXXXX Membership based mutes.md +++ b/proposals/XXXX-membership-based-mutes.md @@ -80,4 +80,4 @@ to implement a version that is based on this MSC before that section is written. ## Dependencies This MSC builds on MSCxxxx, MSCyyyy and MSCzzzz (which at the time of writing have not yet been accepted -into the spec). \ No newline at end of file +into the spec). From 7a2080a9e40efb41b0e5801157b74b00ab36b172 Mon Sep 17 00:00:00 2001 From: Catalan Lover <48515417+FSG-Cat@users.noreply.github.com> Date: Thu, 13 Oct 2022 17:11:57 +0200 Subject: [PATCH 04/11] Fix Dependencies section and update to post publication identifiers --- ...ased-mutes.md => 3909-membership-based-mutes.md} | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) rename proposals/{XXXX-membership-based-mutes.md => 3909-membership-based-mutes.md} (86%) diff --git a/proposals/XXXX-membership-based-mutes.md b/proposals/3909-membership-based-mutes.md similarity index 86% rename from proposals/XXXX-membership-based-mutes.md rename to proposals/3909-membership-based-mutes.md index 928d82679..883a2a793 100644 --- a/proposals/XXXX-membership-based-mutes.md +++ b/proposals/3909-membership-based-mutes.md @@ -1,8 +1,8 @@ -# MSC0000: Membership based mutes WORKING TITLE +# MSC3909: Membership based mutes ## Introduction -As covered in in MSC_POLICY_MUTE currently in matrix mutes are done via powerlevel manipulation. +As covered in in MSC3907 currently in matrix mutes are done via powerlevel manipulation. This MSC has the simple purpose of defining a path forward that alleviates this problem. Yes it does require a room version bump but this MSC will explain why this is an acceptable compromise. @@ -71,7 +71,7 @@ the room. ## Unstable prefix This MSC is not recommended to be implemented before Authorisation rules are properly specified but if implemented. -Please use the version string of `support.feline.mute.mscAAAA.v0` +Please use the version string of `support.feline.mute.msc3909.v0` Once Authorisation rules are specified its expected that the unstable version after that is v1. This is because the pre authorisation rules properly written down version cant be trusted to interoperate and this is why its NOT recommended @@ -79,5 +79,10 @@ to implement a version that is based on this MSC before that section is written. ## Dependencies -This MSC builds on MSCxxxx, MSCyyyy and MSCzzzz (which at the time of writing have not yet been accepted +This MSC builds on MSC3907, MSC3908 and MSC3784 (which at the time of writing have not yet been accepted into the spec). + +It does not require any of these MSCs to be implemented but it works best when implemented together with the rest of these MSCs. + +MSC3907 to cordinate mutes via policy list, MSC3908 to make temporary mutes an option when cordinated via policy lists +and MSC3784 to help enable building better user experiences interacting with policy lists. From c2965769efddbf2ca819489a9bfbd2aca1b18f46 Mon Sep 17 00:00:00 2001 From: Catalan Lover <48515417+FSG-Cat@users.noreply.github.com> Date: Thu, 13 Oct 2022 22:21:02 +0200 Subject: [PATCH 05/11] Clarify that Unmute requires the same PL as issuing a mute. --- proposals/3909-membership-based-mutes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3909-membership-based-mutes.md b/proposals/3909-membership-based-mutes.md index 883a2a793..6841447f6 100644 --- a/proposals/3909-membership-based-mutes.md +++ b/proposals/3909-membership-based-mutes.md @@ -16,7 +16,7 @@ are restricted to exclusively sending the read marker EDUs and nothing more exce their membership to `ban` as defined later. The legal transitions for the `mute` membership type based on Room version 10 would be -`join` -> `mute` -> `ban`, `join`, `leave`(Exclusively via kick) +`join` -> `mute` -> `ban`, `join`(Requires sufficient PL to set membership to `mute`), `leave`(Exclusively via kick) When a users membership is `mute` they may leave the room by setting their own membership to `ban` this transition ignores power levels and instead behaves as if it was a leave. But if the person tries to From ed0fa153305cf11830363bda2c8d54daba211c24 Mon Sep 17 00:00:00 2001 From: Catalan Lover <48515417+FSG-Cat@users.noreply.github.com> Date: Sat, 15 Oct 2022 17:19:59 +0200 Subject: [PATCH 06/11] Fix spelling error. Co-authored-by: Aminda Suomalainen --- proposals/3909-membership-based-mutes.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/3909-membership-based-mutes.md b/proposals/3909-membership-based-mutes.md index 6841447f6..d4458f804 100644 --- a/proposals/3909-membership-based-mutes.md +++ b/proposals/3909-membership-based-mutes.md @@ -40,7 +40,8 @@ deemed acceptable. The reason this is deemed acceptable is because as has been m community moderation teams for multiple communities not all communities want to use mutes in their toolkit and therefore not all communities will feel the need to upgrade their room version to gain access to this feature. -Room version upgrades them self's are being worked upon making more smooth. There is work in the area of deleting state +Room version upgrades themselves are being worked upon making more smooth. There is work in the area of deleting state + for example that requires better room version upgrade mechanics. There is also history importing work being done as another avenue of lessening the impact of room version upgrades in the future. From ec0686b2031c79ed606451f4bc2bdae3d3323640 Mon Sep 17 00:00:00 2001 From: Catalan Lover <48515417+FSG-Cat@users.noreply.github.com> Date: Sat, 15 Oct 2022 17:37:07 +0200 Subject: [PATCH 07/11] Reword bad wording around Room version upgrades --- proposals/3909-membership-based-mutes.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/proposals/3909-membership-based-mutes.md b/proposals/3909-membership-based-mutes.md index d4458f804..f67b7bb8b 100644 --- a/proposals/3909-membership-based-mutes.md +++ b/proposals/3909-membership-based-mutes.md @@ -40,10 +40,9 @@ deemed acceptable. The reason this is deemed acceptable is because as has been m community moderation teams for multiple communities not all communities want to use mutes in their toolkit and therefore not all communities will feel the need to upgrade their room version to gain access to this feature. -Room version upgrades themselves are being worked upon making more smooth. There is work in the area of deleting state - -for example that requires better room version upgrade mechanics. There is also history importing work being done as -another avenue of lessening the impact of room version upgrades in the future. +The UX around room version upgrades is being worked upon to make them less disruptive. There is work in +the area of deleting state for example that requires better room version upgrade mechanics. There is also history importing +work being done as another avenue of lessening the impact of room version upgrades in the future. The authors of this MSC believes that communities that desire to use this MSC to its full potential are perfectly happy to accept the compromises involved in a room version bump. This MSCs purpose can be achieved via powerlevels From 8b845b4ae5f0363b1a4981e7b6319b86742f975b Mon Sep 17 00:00:00 2001 From: Catalan Lover Date: Fri, 10 Mar 2023 22:35:08 +0100 Subject: [PATCH 08/11] Implement Leave-Mute membership --- proposals/3909-membership-based-mutes.md | 40 ++++++++++++++---------- 1 file changed, 23 insertions(+), 17 deletions(-) diff --git a/proposals/3909-membership-based-mutes.md b/proposals/3909-membership-based-mutes.md index f67b7bb8b..717892689 100644 --- a/proposals/3909-membership-based-mutes.md +++ b/proposals/3909-membership-based-mutes.md @@ -9,25 +9,26 @@ require a room version bump but this MSC will explain why this is an acceptable To achieve Mutes via membership a new membership state is proposed of `mute`. It would allow you to exclusively send EDUs and no PDUs. +A passive benefit of this MSC that is notable is that with the introduction of Partial joining of rooms the minimum +state to join said room is important. As far as the authors understand this state is obligatorily going to be +negatively effected by PL events climbing in number. This MSC mittigates this and this is a real world +relevant example of why this MSC matters. ## Proposal This proposal defines the `mute` membership type. If a user has this membership type in a room they are restricted to exclusively sending the read marker EDUs and nothing more except leaving via setting -their membership to `ban` as defined later. +their membership to `leave-mute` as defined later. -The legal transitions for the `mute` membership type based on Room version 10 would be -`join` -> `mute` -> `ban`, `join`(Requires sufficient PL to set membership to `mute`), `leave`(Exclusively via kick) - -When a users membership is `mute` they may leave the room by setting their own membership to `ban` -this transition ignores power levels and instead behaves as if it was a leave. But if the person tries to -re-join the room they will be banned the same way they would be if someone else sent a valid ban. -The reason for going this way is simple. It preserves your ability to leave a room while your muted -but you cant return without the moderators of the room desiring you to have the ability to return. +This proposal also introduces the new membership type of `leave-mute` this special membership +is set if a user leaves the room while their membership is `mute` this way you can still leave +rooms while muted without introducing a security flaw. -This also solves the issue of forcing implementations to break the matrix tradition and evaluate not just -the previous membership state but 2 membership states back to determine if its legal or not that would have been -required to enable leaves. +The legal transitions for the `mute` membership type based on Room version 10 would be +`join` -> `mute` -> `leave-mute`, `join`(Requires sufficient PL to set membership to `mute`), `leave`(Exclusively via kick) +The legal transitions for the `leave-mute` membership type based on Room version 10 would be +`mute` -> `leave-mute` -> `invite`(Requires sufficient PL to set membership to `mute` and to set membership to `invite`) , +`leave-mute`, `leave`(Requires sufficient PL to set membership to `mute`). ### Authorisation rules. @@ -64,19 +65,24 @@ a perfect world be able to be implemented quite quickly in a vacuum that is not The `mute` membership type is going to be yet another thing that you can mess up implementing and that is recognised as an ok. The authors of this MSC believes that is an acceptable compromise since we avoid -the PL churn of current mute implementations. We also believe that the potential issue of being trapped in -rooms is mitigated by making self bans an option to mitigate the potential to bypass a mute fully by leaving -the room. +the PL churn of current mute implementations. The ability to bypass a mute by leaving the room is mittigated +by the `leave-mute` membership type while still allowing full normal functionality except for rejoining a room via invite +as muted. ## Unstable prefix This MSC is not recommended to be implemented before Authorisation rules are properly specified but if implemented. -Please use the version string of `support.feline.mute.msc3909.v0` +Please use the version string of `support.feline.mute.msc3909.v0.1` -Once Authorisation rules are specified its expected that the unstable version after that is v1. This is because the +Once Authorisation rules are specified it's expected that the unstable version after that is v1. This is because the pre authorisation rules properly written down version cant be trusted to interoperate and this is why its NOT recommended to implement a version that is based on this MSC before that section is written. +## Historical Prefixes + +`support.feline.mute.msc3909.v0` was the prefix for the first itteration of the MSC. This prefix was for when self banning +was included. + ## Dependencies This MSC builds on MSC3907, MSC3908 and MSC3784 (which at the time of writing have not yet been accepted From 0a19e137a3cce5456127b9f17cc1c759d47d5c40 Mon Sep 17 00:00:00 2001 From: Catalan Lover <48515417+FSG-Cat@users.noreply.github.com> Date: Sat, 11 Mar 2023 02:05:06 +0100 Subject: [PATCH 09/11] Fix Typo --- proposals/3909-membership-based-mutes.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3909-membership-based-mutes.md b/proposals/3909-membership-based-mutes.md index 717892689..7157a70b4 100644 --- a/proposals/3909-membership-based-mutes.md +++ b/proposals/3909-membership-based-mutes.md @@ -80,7 +80,7 @@ to implement a version that is based on this MSC before that section is written. ## Historical Prefixes -`support.feline.mute.msc3909.v0` was the prefix for the first itteration of the MSC. This prefix was for when self banning +`support.feline.mute.msc3909.v0` was the prefix for the first iteration of the MSC. This prefix was for when self banning was included. ## Dependencies From 57cf14ab5e9935bd8272619a0f51d0e0e4f59d10 Mon Sep 17 00:00:00 2001 From: Catalan Lover Date: Tue, 21 Mar 2023 12:44:40 +0100 Subject: [PATCH 10/11] Add ban as legal transition, Exempt Redactions and clarify EDUs. Nico pointed out in a conversation the issue of that EDU definition was unclear and that we should allow redactions. Ban transitions where also fixed as they had been overlooked. --- proposals/3909-membership-based-mutes.md | 28 +++++++++++++++--------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/proposals/3909-membership-based-mutes.md b/proposals/3909-membership-based-mutes.md index 7157a70b4..07260dba3 100644 --- a/proposals/3909-membership-based-mutes.md +++ b/proposals/3909-membership-based-mutes.md @@ -7,28 +7,29 @@ This MSC has the simple purpose of defining a path forward that alleviates this require a room version bump but this MSC will explain why this is an acceptable compromise. To achieve Mutes via membership a new membership state is proposed of `mute`. It would allow you to -exclusively send EDUs and no PDUs. +exclusively send Read markers and exempt events as defined later. A passive benefit of this MSC that is notable is that with the introduction of Partial joining of rooms the minimum state to join said room is important. As far as the authors understand this state is obligatorily going to be -negatively effected by PL events climbing in number. This MSC mittigates this and this is a real world +negatively effected by PL events climbing in number. This MSC mitigates this and this is a real world relevant example of why this MSC matters. ## Proposal This proposal defines the `mute` membership type. If a user has this membership type in a room they -are restricted to exclusively sending the read marker EDUs and nothing more except leaving via setting -their membership to `leave-mute` as defined later. +are restricted to exclusively sending the read marker EDUs, leaving via setting +their membership to `leave-mute` as defined later and `m.room.redaction` events. This proposal also introduces the new membership type of `leave-mute` this special membership is set if a user leaves the room while their membership is `mute` this way you can still leave rooms while muted without introducing a security flaw. The legal transitions for the `mute` membership type based on Room version 10 would be -`join` -> `mute` -> `leave-mute`, `join`(Requires sufficient PL to set membership to `mute`), `leave`(Exclusively via kick) +`join` -> `mute` -> `leave-mute`, `join`(Requires sufficient PL to set membership to `mute`), `leave`(Exclusively via kick), +`ban`. The legal transitions for the `leave-mute` membership type based on Room version 10 would be `mute` -> `leave-mute` -> `invite`(Requires sufficient PL to set membership to `mute` and to set membership to `invite`) , -`leave-mute`, `leave`(Requires sufficient PL to set membership to `mute`). +`leave-mute`, `leave`(Requires sufficient PL to set membership to `mute`) `ban`. ### Authorisation rules. @@ -65,14 +66,18 @@ a perfect world be able to be implemented quite quickly in a vacuum that is not The `mute` membership type is going to be yet another thing that you can mess up implementing and that is recognised as an ok. The authors of this MSC believes that is an acceptable compromise since we avoid -the PL churn of current mute implementations. The ability to bypass a mute by leaving the room is mittigated -by the `leave-mute` membership type while still allowing full normal functionality except for rejoining a room via invite +the PL churn of current mute implementations. The ability to bypass a mute by leaving the room is mitigated +by the `leave-mute` membership type while still allowing full normal functionality except for re-joining a room via invite as muted. +Because redactions are exempt from Mutes for privacy reasons this does re open the exploit that is closed by denying profile +updates on paper. This exploit does not in practice get reintroduced to any large degree as clients don’t render redact +reasons. And it is recommended that stakeholders that are worried about this abuse path use clients that render so called hidden +events so you can see the redactions to observe if they have suspicious patterns. ## Unstable prefix This MSC is not recommended to be implemented before Authorisation rules are properly specified but if implemented. -Please use the version string of `support.feline.mute.msc3909.v0.1` +Please use the version string of `support.feline.mute.msc3909.v0.2` Once Authorisation rules are specified it's expected that the unstable version after that is v1. This is because the pre authorisation rules properly written down version cant be trusted to interoperate and this is why its NOT recommended @@ -83,6 +88,9 @@ to implement a version that is based on this MSC before that section is written. `support.feline.mute.msc3909.v0` was the prefix for the first iteration of the MSC. This prefix was for when self banning was included. +`support.feline.mute.msc3909.v0.1` was the prefix for the second iteration of the MSC. This prefix was current before +the bug that ban was omitted from the transitions was fixed and redactions are now legal for muted parties to issue. + ## Dependencies This MSC builds on MSC3907, MSC3908 and MSC3784 (which at the time of writing have not yet been accepted @@ -90,5 +98,5 @@ into the spec). It does not require any of these MSCs to be implemented but it works best when implemented together with the rest of these MSCs. -MSC3907 to cordinate mutes via policy list, MSC3908 to make temporary mutes an option when cordinated via policy lists +MSC3907 to coordinate mutes via policy list, MSC3908 to make temporary mutes an option when coordinated via policy lists and MSC3784 to help enable building better user experiences interacting with policy lists. From 28f1f031909f697a14f7633d87cdb13f1dd85d78 Mon Sep 17 00:00:00 2001 From: Catalan Lover <48515417+FSG-Cat@users.noreply.github.com> Date: Thu, 22 Feb 2024 16:01:37 +0100 Subject: [PATCH 11/11] Clarify Mute Restriction wording. Co-authored-by: Patrick Cloke --- proposals/3909-membership-based-mutes.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/3909-membership-based-mutes.md b/proposals/3909-membership-based-mutes.md index 07260dba3..472579e31 100644 --- a/proposals/3909-membership-based-mutes.md +++ b/proposals/3909-membership-based-mutes.md @@ -16,7 +16,8 @@ relevant example of why this MSC matters. ## Proposal This proposal defines the `mute` membership type. If a user has this membership type in a room they -are restricted to exclusively sending the read marker EDUs, leaving via setting +are restricted to exclusively sending receipts, leaving via setting + their membership to `leave-mute` as defined later and `m.room.redaction` events. This proposal also introduces the new membership type of `leave-mute` this special membership