Remove aliases from /publicRooms response

Through attempting to land [Synapse#11667](matrix-org/synapse#11667) it was found that Synapse doesn't return the `aliases` property on `/publicRooms` as it was [removed](matrix-org/synapse#6970) by a [tracking issue](matrix-org/synapse#6898) referencing [MSC2432](#2432) as its base. Though MSC2432 does not make mention of this, the [document](https://docs.google.com/document/d/1NNDkobiFLeUkJtyj0H6qvKIedgvIkZnFKo78-03cGEk/edit) the MSC is based upon makes deliberate effort to mention the endpoint and the removal of `aliases`. Thus, it is determined as a likely accidental omission from the formal MSC and therefore the formal spec. This has been corrected here by amending the MSC (per the process) and removing the field, basing itself off of the [spec PR for spaces](#3610) for diff clarity.
matrix-org · Jan 5, 2022 · 78f2312 · 78f2312
1 parent 7c44985
commit 78f2312
Show file tree

Hide file tree

Showing 6 changed files with 5 additions and 11 deletions.
diff --git a/data/api/client-server/definitions/public_rooms_chunk.yaml b/data/api/client-server/definitions/public_rooms_chunk.yaml
@@ -15,12 +15,6 @@
 type: object
 title: "PublicRoomsChunk"
 properties:
-  aliases:
-    type: array
-    description: Aliases of the room. May be empty.
-    items:
-      type: string
-    example: ["#general:example.org"]
   canonical_alias:
     type: string
     description: The canonical alias of the room, if any.

diff --git a/data/api/client-server/definitions/public_rooms_response.yaml b/data/api/client-server/definitions/public_rooms_response.yaml
@@ -55,7 +55,6 @@ properties:
 example: {
   "chunk": [
     {
-      "aliases": ["#murrays:cheese.bar"],
       "avatar_url": "mxc://bleecker.street/CHEDDARandBRIE",
       "guest_can_join": false,
       "name": "CHEESE",

diff --git a/data/api/client-server/space_hierarchy.yaml b/data/api/client-server/space_hierarchy.yaml
@@ -100,7 +100,6 @@ paths:
                   "join_rule": "public",
                   "room_type": "m.space",
                   "num_joined_members": 42,
-                  "aliases": ["#general:example.org"],
                   "canonical_alias": "#general:example.org",
                   "children_state": [
                     {

diff --git a/data/api/server-server/public_rooms.yaml b/data/api/server-server/public_rooms.yaml
@@ -178,7 +178,6 @@ paths:
             application/json: {
               "chunk": [
                 {
-                  "aliases": ["#murrays:cheese.bar"],
                   "avatar_url": "mxc://bleecker.street/CHEDDARandBRIE",
                   "guest_can_join": false,
                   "name": "CHEESE",

diff --git a/data/api/server-server/space_hierarchy.yaml b/data/api/server-server/space_hierarchy.yaml
@@ -74,7 +74,6 @@ paths:
                 "join_rule": "public",
                 "room_type": "m.space",
                 "num_joined_members": 42,
-                "aliases": ["#general:example.org"],
                 "canonical_alias": "#general:example.org",
                 "allowed_room_ids": [],
                 "children_state": [
@@ -103,7 +102,6 @@ paths:
                   "join_rule": "restricted",
                   "room_type": "m.space",
                   "num_joined_members": 42,
-                  "aliases": ["#general:example.org"],
                   "canonical_alias": "#general:example.org",
                   "allowed_room_ids": [
                     "!upstream:example.org"

diff --git a/proposals/2432-revised-alias-publishing.md b/proposals/2432-revised-alias-publishing.md
@@ -148,6 +148,11 @@ rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) and
    Servers might also choose to allow access to other users such as server
    administrators.
 
+ * [`GET /_matrix/client/r0/publicRooms`](https://matrix.org/docs/spec/client_server/r0.6.0#get-matrix-client-r0-publicrooms) (and the `POST` variant) no longer return
+   `aliases` as part of `PublicRoomsChunk`. Clients do not appear to make use
+   of this field, and `canonical_alias` is maintained to provide similar
+   information.
+
 Various APIs are currently subject to implementation-defined access
 restrictions. No change to the specification is introduced in this regard
 (implementations will continue to be free to impose their own