From 91662bfa7a68205a0360fd13e1960cc4e5ecdf3e Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Mon, 9 Aug 2021 20:02:01 -0400 Subject: [PATCH 1/4] initial text of upgrading invite-only rooms --- proposals/xxxx-upgrading-invite-only-rooms.md | 58 +++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 proposals/xxxx-upgrading-invite-only-rooms.md diff --git a/proposals/xxxx-upgrading-invite-only-rooms.md b/proposals/xxxx-upgrading-invite-only-rooms.md new file mode 100644 index 00000000000..6c236cb789f --- /dev/null +++ b/proposals/xxxx-upgrading-invite-only-rooms.md @@ -0,0 +1,58 @@ +# MSCxxxx: Upgrading invite-only rooms + +Rooms occasionally need to be upgraded to newer versions to take use new +features or for security reasons. When public rooms are upgraded, the new room +is public as well, so users in the old room are able to join the new room +freely. + +However, if the new room are only accessible to invited users (which will +usually be the case when the original room was only accessible to invited +users), users will need to be invited to the new room, which means that the +person who upgrades the room will need to send out many invites. + +Rather than inviting all the members of the old room, we can use [MSC3083: +Restricting room membership based on membership in other +rooms](https://github.com/matrix-org/matrix-doc/pull/3083) to allow members of +the old room to join the new room. + +The spec currently does not define the expected state of the new room when +upgrading a room, but rather recommends that certain state events be copied +over. We propose that the spec should additionally recommend that servers make +use of the `restricted` join rule, where possible and when necessary, to allow +members of the original room to join the new room. + +## Proposal + +When a client requests to upgrade a room using the `POST +/rooms/{roomId}/upgrade` endpoint on a room with `m.room.join_rules` set to +`invite` or `restricted`, and the new room is created with a room version that +supports the `restricted` join rule, the new room should be created with the +`m.room.join_rules` set to `restricted`, and with an `allow` array that +specifies that members of the old room may join, along with any room specified +in the original room's `allow` array, if its join rule was also `restricted`. + +Other tools that are used to upgrade rooms should behave similarly. + +## Potential issues + +None? + +## Alternatives + +As mentioned in the introduction, we could continue to invite members of the +original room to the upgraded room. + +## Security considerations + +The security consideration listed in MSC3083 applies to this proposal as well: + +> Increased trust to enforce the join rules during calls to `/join`, `/make_join`, +> and `/send_join` is placed in the homeservers whose users can issue invites. +> Although it is possible for those homeservers to issue a join event in bad faith, +> there is no real-world benefit to doing this as those homeservers could easily +> side-step the restriction by issuing an invite first anyway. + +## Unstable prefix + +This proposal only changes the behaviour of homeservers, and does not introduce +any new events or endpoints, so no unstable prefix is needed. From 0557107c25cb4dabdfb25e8445a210308d964678 Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Mon, 9 Aug 2021 20:03:54 -0400 Subject: [PATCH 2/4] use MSC number --- ...invite-only-rooms.md => 3325-upgrading-invite-only-rooms.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename proposals/{xxxx-upgrading-invite-only-rooms.md => 3325-upgrading-invite-only-rooms.md} (98%) diff --git a/proposals/xxxx-upgrading-invite-only-rooms.md b/proposals/3325-upgrading-invite-only-rooms.md similarity index 98% rename from proposals/xxxx-upgrading-invite-only-rooms.md rename to proposals/3325-upgrading-invite-only-rooms.md index 6c236cb789f..182952fd637 100644 --- a/proposals/xxxx-upgrading-invite-only-rooms.md +++ b/proposals/3325-upgrading-invite-only-rooms.md @@ -1,4 +1,4 @@ -# MSCxxxx: Upgrading invite-only rooms +# MSC3325: Upgrading invite-only rooms Rooms occasionally need to be upgraded to newer versions to take use new features or for security reasons. When public rooms are upgraded, the new room From 920dcd700a99278de247bcf7109350a44a9d1193 Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Tue, 10 Aug 2021 14:59:11 -0400 Subject: [PATCH 3/4] add some potential issues, alternatives, security considerations --- proposals/3325-upgrading-invite-only-rooms.md | 25 ++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/proposals/3325-upgrading-invite-only-rooms.md b/proposals/3325-upgrading-invite-only-rooms.md index 182952fd637..ef6ce60e67e 100644 --- a/proposals/3325-upgrading-invite-only-rooms.md +++ b/proposals/3325-upgrading-invite-only-rooms.md @@ -35,13 +35,30 @@ Other tools that are used to upgrade rooms should behave similarly. ## Potential issues -None? +This proposal only applies to rooms with `m.room.join_rules` set to `invite` or +`restricted`, and not `knock` since rooms cannot (currently) be set to both +knock and to allow users based on membership in another room. If a future room +version allows both to be used, then this proposal can be extended at that +time. + +If the room is encrypted, users will not receive the keys to decrypt messages +until they join the room. This is similar to the current room upgrade issue +where if the `m.room.history_visibility` is set to `joined`, in which users +will not be able to see messages from before they join. ## Alternatives As mentioned in the introduction, we could continue to invite members of the original room to the upgraded room. +Alternatively, the homeserver that creates the room could set the membership +in the new room for each member of the original room to `invited`, without +actually sending the invite, thus avoiding the problem of invite spam. + +[MSC2214](https://github.com/matrix-org/matrix-doc/pull/2214) proposes a new +state event that indicates a user's membership in the original room, which can +be used to verify if a user is allowed to join the room. + ## Security considerations The security consideration listed in MSC3083 applies to this proposal as well: @@ -52,6 +69,12 @@ The security consideration listed in MSC3083 applies to this proposal as well: > there is no real-world benefit to doing this as those homeservers could easily > side-step the restriction by issuing an invite first anyway. +A user may get kicked from the upgraded room, but still be able to rejoin due +to being a member of the original room. This is in contrast with an +invite-only room, where a user who is kicked cannot rejoin unless they are +re-invited. This can be worked around by banning the user rather than kicking +them. + ## Unstable prefix This proposal only changes the behaviour of homeservers, and does not introduce From 3817d718234fbeee0cdbe5c4b0ea2af4485b5d28 Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Tue, 10 Aug 2021 15:00:20 -0400 Subject: [PATCH 4/4] Update proposals/3325-upgrading-invite-only-rooms.md Co-authored-by: Patrick Cloke --- proposals/3325-upgrading-invite-only-rooms.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3325-upgrading-invite-only-rooms.md b/proposals/3325-upgrading-invite-only-rooms.md index ef6ce60e67e..7cf87155065 100644 --- a/proposals/3325-upgrading-invite-only-rooms.md +++ b/proposals/3325-upgrading-invite-only-rooms.md @@ -5,7 +5,7 @@ features or for security reasons. When public rooms are upgraded, the new room is public as well, so users in the old room are able to join the new room freely. -However, if the new room are only accessible to invited users (which will +However, if the new room is only accessible to invited users (which will usually be the case when the original room was only accessible to invited users), users will need to be invited to the new room, which means that the person who upgrades the room will need to send out many invites.