Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-21 10:54:09 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Add notes from @madlittlemods.

Browse source
This commit is contained in:
Patrick Cloke 2021-05-12 10:58:35 -04:00 committed by Richard van der Hoff
parent 0992a4d60f
commit 933c50480c
1 changed files with 17 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
proposals/3083-restricted-rooms.md
View file

@ -174,13 +174,21 @@ to a space to gain membership to a room.
### Kicking users out when they leave the allowed space ### Kicking users out when they leave the allowed space
In the above example, suppose `@bob:server.example` leaves `!users:example.org`: 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 should they be removed from the room? Likely not, by analogy with what happens
to Bob's server `server.example`, but this places a relatively high level of trust when you switch the join rules from public to invite. Join rules currently govern
in that server. Additionally, if `server.example` were offline, other users in joins, not existing room membership.
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. 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 Fixing this is thorny. Some sort of annotation on the membership events might
help. but it's unclear what the desired semantics are: 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 the `allow` list and SpaceA is removed. What should happen when the
user leaves SpaceB? Are they exempt from the kick? 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 ### Inheriting join rules
If you make a parent space invite-only, should that (optionally?) cascade into If you make a parent space invite-only, should that (optionally?) cascade into