From 684d9979552103053985d6f97c21afdb2e0f4cbf Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Fri, 2 Aug 2019 15:26:05 -0600 Subject: [PATCH 1/2] What if we allowed people to rejoin private rooms? --- proposals/2213-rejoin-private-rooms.md | 88 ++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 proposals/2213-rejoin-private-rooms.md diff --git a/proposals/2213-rejoin-private-rooms.md b/proposals/2213-rejoin-private-rooms.md new file mode 100644 index 00000000..55d2e3ce --- /dev/null +++ b/proposals/2213-rejoin-private-rooms.md @@ -0,0 +1,88 @@ +# Rejoinability of private rooms + +Similar to a house, users in a private room should have the option of joining and +leaving a room provided they have a key to get in. This process shouldn't involve +another user to send an invite once the user has joined at least once. This proposal +has little meaning in a public room as users are welcome to come and go as they +please already. + +An example use case for this would be a direct chat where for de-cluttering one +of the users leaves all direct chats after they become irrelevant. This does +already happen in practice, and often results in the user who left creating multiple +DMs with the other user. [MSC2199](https://github.com/matrix-org/matrix-doc/pull/2199) +covers new DM semantics which benefit from this proposal where users can re-use +DMs even after they've left. + +Another use case, not solved by this proposal, would be to support a group-wide +join rule where members of a given group are able to join the room. This use case +is better solved by [MSC2214](https://github.com/matrix-org/matrix-doc/pull/2214) +however. + +## Proposal + +In a future room version... + +`m.room.join_rules` is expanded to have a new `rejoin_rule` field under `content`, +preserved by the redaction algorithm. The `rejoin_rule` must be one of: + +* `invite`: Members which were previously invited or joined to the room can rejoin, + provided they are now not banned. + +* `join`: Members which were previously joined to the room can rejoin, provided they + are now not banned. + +* `forbidden`: This event cannot be used to authorize a rejoin (members must be + explicitly invited back into the room). This is the default. + +The `rejoin_rule` only takes effect if the `join_rule` for the room is `invite`, +given users can already rejoin the room if the room is public. + +When a join or invite is being processed, the server must first determine if that +user has a prior membership event. If the user does not have a prior membership event, +the `rejoin_rule` does not apply. If the user does have a prior membership event, +the following conditions do apply: + +1. If the previous membership is not explicitly `leave`, `rejoin_rule` does not apply. + For example, bans still ban, invites still invite, and never having been in the room + does not let you use `rejoin_rule` to get in. +2. If the `rejoin_rule` is `forbidden`, or implied to be `forbidden`, reject. +3. If the previous membership is explicitly `leave`, the server must look at the membership + previous to that membership to make a decision: + 1. If the `rejoin_rule` is `join` and the membership previous to `leave` is not `join` + then reject. Else accept. + 2. If the `rejoin_rule` is `invite` and the membership previous to `leave` is not + `join` or `invite`, reject. Else accept. + +In short: the member must `leave` before they can have a `rejoin_rule` allow them in +again. + +**Known limitation**: If the user were to be kicked twice they would not be allowed +back into the room despite a reasonable `rejoin_rule`. This is an intentional limitation +of the proposal to prevent servers from having to traverse the entire room state history +to find a previous membership event. For example, if a server had to traverse the state +history for Matrix HQ (if it were private) every time someone wanted to join the server +could end up exhausting resources. For simplicity, the server is only expected to look +at the last 2 memberships maximum. This limitation can be resolved with a regular invite. + + +## Security considerations + +Room operators are expected to be aware of the room access controls available to them, +much like they are expected to understand the ones currently available. This join rule +alteration may not be applicable to their room, or could open them up to an attack they +are not comfortable with. For this reason, the default behaviour of the proposal is to +maintain existing expectations for join rules. + + +## Alternative solutions + +Instead of re-using the join rules event we could introduce a new state event. Although +possible, and would likely have the same semantics, it is not immediately obvious what +the benefit of more state events would bring to Matrix. It is often preferred to reuse +existing constructs where possible, such as the aptly named "join rules" event. + +Further, this proposal could be done in the form of introducing new `join_rule`s instead +of a new field. Given the `rejoin_rule` only takes effect when `join_rule == "invite"`, +we could redefine the `join_rule` to be `[public, invite, rejoin_invite, rejoin_join]` +or similar. This would simplify the definition, however it does conflate two concerns +and behaviours. From 8867b6cd69dd3ac9af9e44b7c830458f42c6f196 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Fri, 16 Aug 2019 19:12:50 -0600 Subject: [PATCH 2/2] Wording clarifications --- proposals/2213-rejoin-private-rooms.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/proposals/2213-rejoin-private-rooms.md b/proposals/2213-rejoin-private-rooms.md index 55d2e3ce..cf4614a1 100644 --- a/proposals/2213-rejoin-private-rooms.md +++ b/proposals/2213-rejoin-private-rooms.md @@ -35,7 +35,8 @@ preserved by the redaction algorithm. The `rejoin_rule` must be one of: explicitly invited back into the room). This is the default. The `rejoin_rule` only takes effect if the `join_rule` for the room is `invite`, -given users can already rejoin the room if the room is public. +given users can already rejoin the room if the room is public. When the `join_rule` +is any other value, the `rejoin_rule` does not affect the auth for an event. When a join or invite is being processed, the server must first determine if that user has a prior membership event. If the user does not have a prior membership event, @@ -62,7 +63,8 @@ of the proposal to prevent servers from having to traverse the entire room state to find a previous membership event. For example, if a server had to traverse the state history for Matrix HQ (if it were private) every time someone wanted to join the server could end up exhausting resources. For simplicity, the server is only expected to look -at the last 2 memberships maximum. This limitation can be resolved with a regular invite. +at the most recent 2 memberships maximum, as per above. This limitation can be resolved +with a regular invite. ## Security considerations