From fab5eaa67bdf40dcc5cac03dab773909d55db34e Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Wed, 12 May 2021 10:58:35 -0400 Subject: [PATCH] Add notes from @madlittlemods. --- proposals/3083-restricted-rooms.md | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/proposals/3083-restricted-rooms.md b/proposals/3083-restricted-rooms.md index f7846aed..d6f4ee33 100644 --- a/proposals/3083-restricted-rooms.md +++ b/proposals/3083-restricted-rooms.md @@ -174,13 +174,21 @@ to a space to gain membership to a room. ### Kicking users out when they leave the allowed space In the above example, suppose `@bob:server.example` leaves `!users:example.org`: -they should be removed from the room. One option is to leave the departure up -to Bob's server `server.example`, but this places a relatively high level of trust -in that server. Additionally, if `server.example` were offline, other users in -the room would still see Bob in the room (and their servers would attempt to -send message traffic to it). +should they be removed from the room? Likely not, by analogy with what happens +when you switch the join rules from public to invite. Join rules currently govern +joins, not existing room membership. -Another consideration is that users may have joined via a direct invite, not via access through a space. +It is left to a future MSC to consider this, but some potential thoughts are +given below. + +If you assume that a user *should* be removed in this case, one option is to +leave the departure up to Bob's server `server.example`, but this places a +relatively high level of trust in that server. Additionally, if `server.example` +were offline, other users in the room would still see Bob in the room (and their +servers would attempt to send message traffic to it). + +Another consideration is that users may have joined via a direct invite, not via +access through a space. Fixing this is thorny. Some sort of annotation on the membership events might help. but it's unclear what the desired semantics are: @@ -193,6 +201,9 @@ help. but it's unclear what the desired semantics are: the `allow` list and SpaceA is removed. What should happen when the user leaves SpaceB? Are they exempt from the kick? +It is possible that completely different state should be kept, or a different +`m.room.member` state could be used in a more reasonable way to track this. + ### Inheriting join rules If you make a parent space invite-only, should that (optionally?) cascade into