Notes on propagating PLs etc

proposals/1772-groups-as-rooms.md

@@ -6,6 +6,7 @@ This obsoletes [MSC1215](https://github.com/matrix-org/matrix-doc/issues/1215).
 
 Collecting rooms together into groups is useful for a number of
 purposes. Examples include:
+
  * Allowing users to discover different rooms related to a particular topic:
    for example "official matrix.org rooms".
  * Allowing administrators to manage permissions across a number of rooms: for
@@ -61,14 +62,16 @@ Spaces are referred to primarily by their alias, for example
 `#foo:matrix.org`.
 
 Space-rooms are distinguished from regular messaging rooms by the `m.room.type`
-of `m.space` (see [MSC1840](https://github.com/matrix-org/matrix-doc/pull/1840)).
+of `m.space` (see
+[MSC1840](https://github.com/matrix-org/matrix-doc/pull/1840)). XXX nobody has
+convinced me this is actually required.
 
 We introduce an `m.space.child` state event type, which defines the rooms
 within the space. The `state_key` is an alias for a child room, and `present:
 true` key is included to distinguish from a deleted state event. Something
 like:
 
-```json
+```js
 {
     "type": "m.space.child",
     "state_key": "#room1:example.com",
@@ -94,6 +97,17 @@ like:
 }
 ```
 
+XXX if we use aliases here, and we are using it to maintain a tree of rooms in
+the room list, what happens when the alias gets repointed and we don't know
+about it? Maybe room IDs would be better, though the interaction with room
+upgrades would need considering.
+
+XXX Rooms also need to be able to advertise related spaces, so that users can
+discover other, related, rooms.
+
+XXX We also want to be have "secret" rooms within a heirarchy: do this with
+either a "parent" state in the child, or possibly by hashing the room id?
+
 Space-rooms may have `m.room.name` and `m.room.topic` state events in the same
 way as a normal room.
 
@@ -118,7 +132,7 @@ Join rules, invites and 3PID invites work as for a normal room.
 
 ### Long description
 
-We would like to allow groups to have a long description using rich
+We would like to allow spaces to have a long description using rich
 formatting. This will use a new state event type `m.room.description` (with
 empty `state_key`) whose content is the same format as `m.room.message` (ie,
 contains a `msgtype` and possibly `formatted_body`).
@@ -128,11 +142,147 @@ TODO: this could also be done via pinned messages. Failing that
 
 ### Inheritance of power-levels
 
-TODO
+XXX: this section still in progress
+
+One use-case for spaces is to help manage power levels across a group of
+rooms. For example: "Jim has just joined the management team at my company. He
+should have moderator rights across all of the company rooms."
+
+Since the event-authorisation rules cannot easily be changed, we must map any
+changes in space membership onto real `m.room.power_levels` events in the child
+rooms.
+
+There are two parts to this: one, indicating the relationship, and second, the
+mechanics of propagating changes into real `m.room.power_levels` events.
+
+#### Representing the mapping from spaces to power levels
+
+ * Option 1: list the PLs which should apply in all child rooms in an event in
+   the parent. 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.
+
+ * Option 2: Express the desired PLs as state in the child rooms
+
+   This will need to be an ordered list, so that overlaps have defined behaviour:
+
+   ```js
+   {
+       "type": "m.room.power_level_mappings",
+       "state_key": "",
+       "content": {
+           "mappings": [
+               {
+                   "users": ["@superuser:matrix.org"],
+                   "power_level": 100,
+               },
+               {
+                   "spaces": ["#mods:example.org"],
+                   "power_level": 50,
+               }
+           ]
+       }
+   }
+   ```
+
+   The intention would be that an automated process would peek into
+   `#mods:example.org` and
+
+   Problem 1: possibly hard to map onto a comprehensible UI?
+
+   Problem 2: scope for getting wildly out of sync?
+
+   Question: is it safe to use an alias to refer to a space here? What happens
+   if the alias gets repointed and we don't notice?
+
+#### Propagating changes into rooms
 
-### Automated joins/leaves
+ * Push-based:
 
-TODO
+   * 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: Bob may not want to be a member of all such rooms.
+
+   * We nominate a non-human "group admin" which is responsible for propagating
+     the changes into child rooms. It observes changes made in the parent space
+     and performs the necessary copying actions.
+
+     Problem: Control is now centralised on the homeserver of the admin bot. If
+     that server goes down, changes are no longer propagated correctly.
+
+   * We make it possible to specify several "group admin bot" users as above,
+     on different servers. All of them must have membership and admin in all
+     child rooms. Between them, they keep the child rooms in sync.
+
+     Problem: How do the bots decide which will actually make the changes?
+       * Maybe a random delay is good enough to avoid too much glare?
+       * Or the humans nominate an "active" bot, with the others acting as
+         standbys until they are promoted?
+
+ * Pull-based: the user that created the relationship (or rather, their
+   homeserver) is responsible for copying access controls into the room.
+
+   This has the advantage that users can set up their own spaces to mirror a
+   space, without having any particular control in that group. (XXX: Is that
+   actually a useful feature, at least as far as PLs are concerned?)
+
+   Problem: What do you do if the admin who sets ip the PL relationship
+   disappears?  Again, either the humans have to step in and create a new
+   admin, or maybe we can have multiple admins with random backoff?
+
+   Problem 2: What if the group server you are peeking to to maintain state is
+   unreachable? You could specify multiple vias for different servers via which
+   you can peek?
+
+All of the above solutions share the common problem that if the admin user
+(human or virtual) loses membership or admin rights in the child room, then
+the room will get out of sync.
+
+### Membership restrictions
+
+XXX: this section still in progress
+
+Another desirable feature is to give room admins the power to restrict
+membership of their room based on the membership of spaces<sup
+id="a1">[1](#f1)</sup> (and by implication, when a user leaves the required
+space, they should be ejected from the room). For example, "Any members of the
+#doglovers space can join this room".
+
+### Automated joins
+
+XXX: this section still in progress
+
+A related feature is: "all members of the company should automatically join the
+#general room", and by extension "all users should automatically join the
+#brainwashing room and may not leave".
 
 ## Future extensions
 
@@ -151,6 +301,8 @@ Questions to be answered here include:
  * What happens if somebody defines a cycle? (It's probably fine, but anything
    interpreting the relationships needs to be careful to limit recursion.)
 
+XXX seems we need to un-de-scope this.
+
 ### Restricting access to the spaces membership list
 
 In the existing `/r0/groups` API, the group server has total control over the
@@ -238,3 +390,12 @@ namespace. For example, `m.space.child` becomes
 
  * This replaces MSC1215: https://docs.google.com/document/d/1ZnAuA_zti-K2-RnheXII1F1-oyVziT4tJffdw1-SHrE
  * Other thoughts that led into this are at: https://docs.google.com/document/d/1hljmD-ytdCRL37t-D_LvGDA3a0_2MwowSPIiZRxcabs
+
+
+## Footnotes
+
+<a id="f1"/>[1]: The converse, "anybody can join, provided they are not members
+of the '#catlovers' space" is less useful since (a) users in the banned space
+could simply leave it at any time; (b) this functionality is already somewhat
+provided by [Moderation policy
+lists](https://matrix.org/docs/spec/client_server/r0.6.1#moderation-policy-lists).  [↩](#a1)