Record alternatives

make sure we have records of dismissed alternatives

proposals/1772-groups-as-rooms.md

@@ -258,6 +258,9 @@ This means that a new `m.room.power_levels` event would be generated whenever
 the membership of either `!mods` or `!users` changes. If a user is in both
 spaces, `!mods` takes priority because that is listed first.
 
+If `mappings` is not a list, the whole event is ignored. Any entries in the list
+which do not match the expected format are ignored.
+
 #### Implementing the mapping
 
 When a new room is created, the server implicitly adds a "room admin bot" to
@@ -284,6 +287,139 @@ access to it is itself restricted via `power_levels`. This could be enforced by
 the admin bot so that no `m.room.power_levels` events are generated unless
 `power_level_mappings` is appropriately restricted.
 
+Some sort of rate-limiting may be required to handle the case where the mapped
+space has a high rate of membership churn.
+
+#### Alternatives
+
+Things that were considered and dismissed:
+
+* Rather than defining the mapping in the room, define a template power-levels
+  event in a parent space, which will be inherited by all child rooms. For example:
+
+  ```js
+  {
+      "type": "m.space.child_power_levels",
+      "state_key": "",
+      "content": {
+          // content as per regular power_levels event
+      }
+  }
+  ```
+
+  Problem 1: No automated mapping from space membership to user list, so the
+  user list would have to be maintained manually. On the other hand, this
+  could be fine in some situations, where we're just using the space to group
+  together rooms, rather than as a user list.
+
+  Problem 2: No scope for nuance, where different rooms have slightly
+  different PLs.
+
+  Problem 3: what happens to rooms where several spaces claim it as a child?
+  They end up fighting?
+
+  Problem 4: Doesn't allow for random room admins to delegate their PLs to a
+  space without being admins in that space.
+
+* To implemplement the mapping, we require any user who is an admin in the
+  space (ie, anyone who has permission to change the access rights in the
+  space) to also be admins and members of any child rooms.
+
+  Say Bob is an admin in #doglovers and makes a change that should be
+  propagated to all children of that space. His server is then responsible
+  for generating a power-levels event on his behalf for each room.
+
+  Problem 1: Bob may not want to be a member of all such rooms.
+
+  Problem 2: It will feel odd that Bob's user is seen to be generating PL
+  events every time someone comes and goes from the space.
+
+  Problem 3: It doesn't allow users to set up their own rooms to mirror a
+  space, without having any particular control in that space (though it is
+  questionable if that is actually a useful feature, at least as far as PLs are
+  concerned.)
+
+* Another alternative for implementing the mapping: the user that created the
+  relationship event (or rather, their homeserver, using the user's ID) is
+  responsible for copying access controls into the room.
+
+  Problem 1: What do you do if the admin who sets up the PL relationship
+  disappears? The humans have to step in and create a new admin?
+
+  Problem 2: Again it seems odd that these PL changes come from a single user.
+
+* Is it possible to implement the mappings from multiple users, some of which
+  may not have PL 100? After all it's possible to set rooms up so that you can
+  change PL events without having PL 100.
+
+  It gets horribly messy very quickly, where some admin users can make some
+  changes. So some get supressed and then get made later anyway by a different
+  admin user?
+
+* Is it possble to apply finer-grained control to the
+  `m.room.power_level_mappings` event than "you must be max(PL)"? Applying
+  restrictions post-hoc (ie, having the admin bot ignore settings which were
+  set by underpriviledged users) is an absolute minefield. It might be possible
+  to apply restrictions at the point that the event is set, but it sounds
+  fiddly and it's not clear there is a real use-case.
+
+* This solution smells a bit funny because of the expansions (causing all the
+  redundant mxids everywhere as the groups constantly get expanded every time
+  something happens).
+
+  * Could we could put a hash of the space membership in the PL instead of
+    expanding the wole list, so that servers have a way to check if they are
+    applying the same list as everyone else?
+
+    Feels like it will have bad failure modes: what is a server supposed to do
+    when the hash doesn't match?
+
+  * Could version the space memberships, so you can compare with the source of
+    the space membership data?
+
+  * PL events just record the delta from the previous one? (So a new server
+    would need to get all the PLs ever, but… is that a bad thing?)  ... maybe
+
+  These optimisations can all be punted down the road to a later room version.
+
+* Other ways of handling the merge of automatic and manual PL settings:
+
+  * Add hints to the automated mapper so that it can maintain manually-assigned
+    PLs. This could either be another field in `power_levels` which plays no
+    part in event auth:
+
+    ```js
+    {
+        "type": "m.room.power_levels",
+        "content": {
+            "users": {
+                "@roomadmin:example.com": 100,
+                "@spaceuser1:example.org": 50
+            },
+            "manual_users": {
+                "@roomadmin:example.com": 100
+            }
+        }
+    }
+    ```
+
+    ... or stored in a separate event. Clients would be responsible for updating
+    both copies of the manually-assigned PLs on change.
+
+    Problem: Requiring clients to make two changes feels fragile. What if they
+    get it wrong? what if they don't know about the second copy because they
+    haven't been designed to work in rooms in spaces?
+
+  * Require that even regular PLs go through the automated mapper, by making
+    them an explicit input to that mapper, for example with entries in the
+    `m.room.power_level_mappings` event suggested above.
+
+    Problem: Requires clients to distinguish between rooms where there is an
+    automated mapper, and those where the client should manipulate the PLs
+    directly. (Maybe that's not so bad? The presence of the `mappings` event
+    should be enough? But still sucks that there are two ways to do the same
+    thing, and clients which don't support spaces will get it wrong.)
+
 ### Restricting room membership based on space membership
 
 A desirable feature is to give room admins the power to restrict membership of
@@ -376,6 +512,24 @@ help. but it's unclear what the desired semantics are:
    the `allowed_spaces` list and SpaceA is removed. What should happen when the
    user leaves SpaceB? Are they exempt from the kick?
 
+#### Alternatives
+
+* Maintain some sort of pre-approved list as the space membership changes in a
+  similar way to the PL mapping, possibly via a new membership state.
+
+  Could lead to a lot of membership churn, from a centralised control point.
+
+* Base it on invite-only rooms, and generate invite events on the fly. Kind-of
+  ok, except that we'd want the invites to be seen as having a sender of a
+  management bot rather than an arbitrary user, which would mean that all joins
+  would have to go through that one server (even from servers that were already
+  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
+  does not exempt you from the `allowed_spaces` requirements. This would be
+  simpler to implement, but probably doesn't match the expected UX.
+
 ## Future extensions
 
 The following sections are not blocking parts of this proposal, but are
@@ -468,8 +622,8 @@ These dependencies are shared with profiles-as-rooms
   different querying users. (It may be possible to simulate this behaviour
   using smaller spaces).
 
-## Unstable prefix
 
+## Unstable prefix
 
 The following mapping will be used for identifiers in this MSC during
 development: