From e323ade5f706f0d77f34170828d4985ab94ccc8a Mon Sep 17 00:00:00 2001
From: Richard van der Hoff <richard@matrix.org>
Date: Mon, 9 Nov 2020 15:11:16 +0000
Subject: [PATCH] Switch to room IDs

---
 proposals/1772-groups-as-rooms.md | 39 ++++++++++++++-----------------
 1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/proposals/1772-groups-as-rooms.md b/proposals/1772-groups-as-rooms.md
index 72e4c0c7..a0b9ff2c 100644
--- a/proposals/1772-groups-as-rooms.md
+++ b/proposals/1772-groups-as-rooms.md
@@ -73,23 +73,26 @@ to structure the user's room list into a tree view. The parent/child
 relationship can be expressed in one of two ways:
 
  1. The admins of a space can advertise rooms and subspaces for their space by
-    setting `m.space.child` state events. The `state_key` is an alias for a
-    child room or space, and `present: true` key is included to distinguish
-    from a deleted state event. Something like:
+    setting `m.space.child` state events. The `state_key` is the ID of a child
+    room or space, and the content should ontain a `via` key which gives a list
+    of candidate servers that can be used to join the room. `present: true` key
+    is included to distinguish from a deleted state event. Something like:
 
     ```js
     {
         "type": "m.space.child",
-        "state_key": "#room1:example.com",
+        "state_key": "!abcd:example.com",
         "content": {
+            "via": ["example.com", "test.org"],
             "present": true
         }
     }
 
     {
         "type": "m.space.child",
-        "state_key": "#room2:example.com",
+        "state_key": "!efgh:example.com",
         "content": {
+            "via": ["example.com"],
             "present": true,
             "order": "abcd",
             "default": true
@@ -99,7 +102,7 @@ relationship can be expressed in one of two ways:
     // no longer a child room
     {
         "type": "m.space.child",
-        "state_key": "#oldroom:example.com",
+        "state_key": "!jklm:example.com",
         "content": {}
     }
     ```
@@ -115,20 +118,15 @@ relationship can be expressed in one of two ways:
 
     If `default` is set to `true`, that indicates a "default child": see [below](#default-children).
 
-    XXX if we use aliases here, what happens when the alias gets repointed and
-    we don't know about it? Or we are already in a room which *claims* to be
-    `#room1:example.com`, but actually isn't? Probably room IDs (+ vias) would
-    be better, though the interaction with room upgrades would need
-    considering.
-
  2. Separately, rooms can claim parents via `m.room.parent` state
-    events, where the `state_key` is the alias (?) of the parent space:
+    events, where the `state_key` is the room ID of the parent space:
 
     ```js
     {
         "type": "m.room.parent",
-        "state_key": "#space1:example.com",
+        "state_key": "!space:example.com",
         "content": {
+            "via": ["example.com"]
             "present": true
         }
     }
@@ -249,11 +247,13 @@ mechanics of propagating changes into real `m.room.power_levels` events.
        "content": {
            "mappings": [
                {
-                   "spaces": ["#mods:example.org"],
+                   "space": "!mods:example.org",
+                   "via": ["example.org"],
                    "power_level": 50
                },
                {
-                   "spaces": ["#users:example.org"],
+                   "space": "!users:example.org",
+                   "via": ["example.org"],
                    "power_level": 1
                }
            ]
@@ -262,18 +262,15 @@ mechanics of propagating changes into real `m.room.power_levels` events.
    ```
 
    The intention would be that an automated process would peek into
-   `#mods:example.org` and `#users:example.org` and generate a new
+   `!mods:example.org` and `!users:example.org` and generate a new
    `m.room.power_levels` event whenever the membership of either space
-   changes. If a user is in both spaces, `#mods` takes priority because that is
+   changes. If a user is in both spaces, `!mods` takes priority because that is
    listed first.
 
    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?
-
    XXX Question: currently there are restrictions which stop users assigning PLs
    above their own current power level. Do we need to replicate these
    restrictions? If so, that probably necessitates changes to event auth? (Does