matrix-doc/proposals/4060-room-rules.md

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

Proposal

A new m.room.rules state event with empty string state key is defined to contain the rules themselves. Like MSC3765, this is done using Extensible Events:

{
  "type": "m.room.rules",
  "state_key": "",
  "content": {
    "m.text": [
      {"body": "1. Don't be mean\n2. Be kind"},
      {"mimetype": "text/html", "body": "<ol><li>Don't be mean</li><li>Be kind</li></ol>"}
    ]
  }
  // other fields not shown
}

A user "accepts" the rules by referencing the rules event. TODO: Pick method.

TODO: Options include:

1. MSC4058 - the accepting user adds some structured metadata to the rules event.
2. MSC4059 - if changed to support mutations from unoriginal senders, mutating the event content in some way. This is probably dangerous though.
3. Event relationships - 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-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.