Switch to room IDs

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
+    setting `m.space.child` state events. The `state_key` is the ID of a child
-    child room or space, and `present: true` key is included to distinguish
+    room or space, and the content should ontain a `via` key which gives a list
-    from a deleted state event. Something like:
+    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