From b391f4576ac77adb8d847888bbaee5c9e6138b49 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Fri, 13 Oct 2023 21:43:10 -0600 Subject: [PATCH 1/2] MSC: Accept room rules before speaking --- proposals/4060-room-rules.md | 101 +++++++++++++++++++++++++++++++++++ 1 file changed, 101 insertions(+) create mode 100644 proposals/4060-room-rules.md diff --git a/proposals/4060-room-rules.md b/proposals/4060-room-rules.md new file mode 100644 index 00000000000..908d9b7aa8f --- /dev/null +++ b/proposals/4060-room-rules.md @@ -0,0 +1,101 @@ +# MSC4060: Accept room rules before speaking + +A common feature among other chat platforms is a requirement for users to +acknowledge that they've read the room's rules before they're allowed to send +a message. It's typically a challenge to implement such a feature reliably as +there's rarely anything preventing an automated client from accepting the rules +and promptly spamming, however for the typical case a sufficient barrier is +simply one which appears *most* of the time in front of users. + +This proposal introduces a feature where rooms can define rules that users must +accept before they're allowed to speak. Perhaps controversially, this MSC does +*not* require a new room version as it does not tie acceptance of the rules into +the event authorization rules. This is a deliberate choice as a change in rules +would consitute a requirement that all past agreements are rendered invalid, +which may be a desired trait in some communities but not all. This is explored +in a little bit more detail in the Alternatives section. + +## Proposal + +A new `m.room.rules` state event with empty string state key is defined to +contain the rules themselves. Like [MSC3765](https://github.com/matrix-org/matrix-spec-proposals/pull/3765), +this is done using Extensible Events: + +```jsonc +{ + "type": "m.room.rules", + "state_key": "", + "content": { + "m.text": [ + {"body": "1. Don't be mean\n2. Be kind"}, + {"mimetype": "text/html", "body": "
  1. Don't be mean
  2. Be kind
"} + ] + } + // other fields not shown +} +``` + +A user "accepts" the rules by referencing the rules event. **TODO**: Pick method. + +**TODO**: Options include: + +1. [MSC4058](https://github.com/matrix-org/matrix-spec-proposals/pull/4058) - + the accepting user adds some structured metadata to the rules event. +2. [MSC4059](https://github.com/matrix-org/matrix-spec-proposals/pull/4059) - + if changed to support mutations from unoriginal senders, mutating the event + content in some way. This is probably dangerous though. +3. [Event relationships](https://spec.matrix.org/v1.8/client-server-api/#forming-relationships-between-events) - + like we've done for pretty much everything else. + +When `m.room.rules` is present in a room, and the user hasn't accepted them, the +client SHOULD prompt the user to accept the rules before allowing them to send +a message. In this MSC, it is expected that a bot will enforce acceptance before +allowing the user to send a message. For example, redacting all of the user's +events. + +Servers SHOULD require the user to accept the rules before allowing them to send +events in the room. + +Notable exceptions for clients, servers, and moderation bots are events which +are required for accepting the rules and membership events (ie: leaving rather +than accepting). + +It is expected that a future MSC will define a structure or system to *require* +acceptance of the rules at the room level, potentially tied into a +[MSC4056](https://github.com/matrix-org/matrix-spec-proposals/pull/4056)-style +role. Using a role would allow a subset of users to bypass the rules (in cases +where they can't be bridged, for example), require this MSC's soft limit +approach, or enforce the rules via event authorization. + +## Potential issues + +**TODO**: Detail. + +## Alternatives + +This MSC deliberately does not tie acceptance of the rules into the event +authorization algorithm. Doing so with the current power level structure in +Matrix rooms could potentially lead to over-imposed opinions on what it means +to "speak" in a room, as well as requiring users to frequently accept rule +changes. + +Instead, this MSC asks that a bot or local server make the decisions on what is +allowable before acceptance, and whether the rules need to be accepted every +time or not. It is expected that the protocol will eventually support many of +the constraints implemented by these servers and bots through future MSCs, such +as the role-based access control approach described in the proposal text above. + +## Security considerations + +**TODO**: Detail. + +## Unstable prefix + +While this MSC is not considered stable, implementations should use +`org.matrix.msc4060.room.rules` in place of `m.room.rules`. + +**TODO**: Describe prefix for "accepting" the rules too. + +## Dependencies + +**TODO**: Declare. From 8fe5af46ea97db0cf98354c36d21544b7ac571ea Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Fri, 13 Oct 2023 21:46:02 -0600 Subject: [PATCH 2/2] spelling --- proposals/4060-room-rules.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4060-room-rules.md b/proposals/4060-room-rules.md index 908d9b7aa8f..997ad76aa7a 100644 --- a/proposals/4060-room-rules.md +++ b/proposals/4060-room-rules.md @@ -11,7 +11,7 @@ This proposal introduces a feature where rooms can define rules that users must accept before they're allowed to speak. Perhaps controversially, this MSC does *not* require a new room version as it does not tie acceptance of the rules into the event authorization rules. This is a deliberate choice as a change in rules -would consitute a requirement that all past agreements are rendered invalid, +would constitute a requirement that all past agreements are rendered invalid, which may be a desired trait in some communities but not all. This is explored in a little bit more detail in the Alternatives section.