Descope autokick and rename allowed_spaces

proposals/1772-groups-as-rooms.md

@@ -435,7 +435,7 @@ We could represent the allowed spaces with additional content in the
     "state_key": "",
     "content": {
         "join_rule": "public",
-        "allowed_spaces": [
+        "allowed_join": [
             {
                 "space": "!mods:example.org",
                 "via": ["example.org"],
@@ -453,11 +453,12 @@ XXX: would it be better to put it in a separate event? Doing so would probably
 require us to come up with a new `join_rule` state to tell servers to go and
 look for the allowed spaces.
 
-The `allowed_spaces` key applies a restriction to the `public` join rule, so
+The `allowed_join` key applies a restriction to the `public` join rule, so that
-that only users in those spaces should be allowed to join. Additionally, users
+only users satisfying one or more of the requirements should be allowed to
-who have received an explicit `invite` event are allowed to join<sup
+join. Additionally, users who have received an explicit `invite` event are
-id="a2">[2](#f2)</sup>. If the `allowed_spaces` key is an empty list (or not a
+allowed to join<sup id="a2">[2](#f2)</sup>. If the `allowed_join` key is an
-list at all), no users are allowed to join without an invite.
+empty list (or not a list at all), no users are allowed to join without an
+invite.
 
 Unlike the regular `invite` join rule, the restriction cannot be enforced over
 federation by event authorization, so servers in the room are trusted not to
@@ -471,10 +472,13 @@ permitted if the user has a valid invite or is in one of the listed spaces
 XXX: redacting the join_rules above will reset the room to public, which feels dangerous?
 
 A new room version is not absolutely required here, but may be advisable to
-ensure that servers that do not support `allowed_spaces` do not join the room
+ensure that servers that do not support `allowed_join` do not join the room
 (and would also allow us to tweak the redaction rules to avoid the foot-gun).
 
-#### Kicking users out when they leave the allowed_space
+#### Kicking users out when they leave the allowed space
+
+XXX: this will probably be a future extension, rather than part of the initial
+implementation of `allowed_join`.
 
 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
@@ -484,18 +488,18 @@ the room would still see Bob in the room (and their servers would attempt to
 send message traffic to it).
 
 Instead, we make the removal the responsibility of the room's admin bot (see
-above): the bot is expected to peek into any `allowed_spaces` and kick any
+above): the bot is expected to peek into any spaces in `allowed_join` and kick
-users who are members of the room and leave the union of the allowed
+any users who are members of the room and leave the union of the allowed
 spaces.
 
 (XXX: should users in a space be kicked when that space is removed from the
-`allowed_spaces` list? We think not, by analogy with what happens when you
+`allowed_join` list? We think not, by analogy with what happens when you switch
-switch the join rules from `public` to `invite`.)
+the join rules from `public` to `invite`.)
 
 One problem here is that it will lead to users who joined via an invite being
 kicked. For example:
  * `@bob:server.example` creates an invite-only room.
- * Later, the `join_rules` are switched to `public`, with an `allowed_space` of
+ * Later, the `join_rules` are switched to `public`, with an `allowed_join` of
    `!users:example.org`, of which Bob happens to be a member.
  * Later still, Bob leaves `!users:example.org`.
  * Bob is kicked from his own room.
@@ -504,12 +508,12 @@ Fixing this is thorny. Some sort of annotation on the membership events might
 help. but it's unclear what the desired semantics are:
 
  * Assuming that users in a given space are *not* kicked when that space is
-   removed from `allowed_spaces`, are those users then given a pass to remain
+   removed from `allowed_join`, are those users then given a pass to remain
    in the room indefinitely? What happens if the space is added back to
-   `allowed_spaces` and *then* the user leaves it?
+   `allowed_join` and *then* the user leaves it?
 
  * Suppose a user joins a room via a space (SpaceA). Later, SpaceB is added to
-   the `allowed_spaces` list and SpaceA is removed. What should happen when the
+   the `allowed_join` list and SpaceA is removed. What should happen when the
    user leaves SpaceB? Are they exempt from the kick?
 
 #### Alternatives
@@ -526,8 +530,8 @@ help. but it's unclear what the desired semantics are:
   participating in the room), which feels a bit grim. We could have multiple
   admin bots to mitigate this, but it gets a bit messy.
 
-* Change the way that `allowed_spaces` and invites interact, so that an invite
+* Change the way that `allowed_join` and invites interact, so that an invite
-  does not exempt you from the `allowed_spaces` requirements. This would be
+  does not exempt you from the `allowed_join` requirements. This would be
   simpler to implement, but probably doesn't match the expected UX.
 
 ## Future extensions
@@ -598,14 +602,16 @@ These dependencies are shared with profiles-as-rooms
 
 ## Security considerations
 
-* The peek server has significant power. TODO: expand.
+* The peek server has significant power. For example, a poorly chosen peek
+  server could lie about the space membership and add an
+  `@evil_user:example.org`.
 
-* The `allowed_spaces` feature places increased trust in the servers in the
+* The `allowed_join` feature places increased trust in the servers in the
   room. We consider this acceptable: if you don't want evil servers randomly
   joining spurious users into your rooms, then a) don't let evil servers in
-  your room in the first place, b) don't use `allowed_spaces` lists, given the
+  your room in the first place, b) don't use `allowed_join` lists, given the
   expansion increases the attack surface anyway by letting members in other
-  rooms dictate who's allowed into your room".
+  rooms dictate who's allowed into your room.
 
 ## Tradeoffs
 
@@ -634,7 +640,7 @@ Proposed final identifier       | Purpose | Development identifier
 `m.space.parent` | event type | `org.matrix.msc1772.space.parent`
 `m.room.power_level_mappings` | event type | `org.matrix.msc1772.room.power_level_mappings`
 `auto_users` | key in `m.room.power_levels` event | `org.matrix.msc1772.auto_users`
-
+`allowed_join` | key in `m.room.join_rules` event | `org.matrix.msc1772.allowed_join`
 
 ## History