From d5ddccbb6900c94311d493adbf09e716fe0bc31a Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Tue, 17 Nov 2020 14:06:29 +0000 Subject: [PATCH] Cross-room threading: move room_id/servers to unsigned --- proposals/2836-threading.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/proposals/2836-threading.md b/proposals/2836-threading.md index 4193e99c..30f28188 100644 --- a/proposals/2836-threading.md +++ b/proposals/2836-threading.md @@ -156,7 +156,7 @@ Server implementation: #### Cross-room threading extension This MSC expands on the basic form to allow cross-room threading by allowing 2 extra fields to be specified -in the `m.relationship` object: `servers` and `room_id`: +in the `unsigned` section of the event: `relationship_servers` and `relationship_room_id`: ``` { "type": "m.room.message", @@ -165,20 +165,22 @@ in the `m.relationship` object: `servers` and `room_id`: "m.relationship": { "rel_type": "m.reference", "event_id": "$another_event_id", - "servers": [ "localhost", "anotherhost" ], - "room_id": "!someroomid:anotherhost", } + }, + "unsigned": { + "relationship_room_id":"!someroomid:anotherhost", + "relationship_servers": [ "localhost", "anotherhost" ] } } ``` -Only servers can set these fields. If clients attempt to set them they will be replaced. The server should set these fields +Only servers can set these fields. The server should set these fields when an event is sent according to the following rules: - Check the client can view the event ID in question. If they cannot, reject the request. - Check that the room's `m.room.create` event allows cross-room threading by the presence of `"m.cross_room_threading": true` in the `content` field. If absent, it is `false`. - - Fetch the servers *currently in the room* for the event. Add them all to `servers`. - - Fetch the room ID that the event belongs to. Add it to `room_id`. + - Fetch the servers *currently in the room* for the event. Add them all to `relationship_servers`. + - Fetch the room ID that the event belongs to. Add it to `relationship_room_id`. This proposal does not require any changes to `/createRoom` as `"m.cross_room_threading": true` can be specified via the `creation_content` field in that API. @@ -188,12 +190,12 @@ The `POST /relationships` endpoint includes a new field: in order to explore the thread. Default: `false`. Server implementation: - - When walking the thread DAG, if there is an event that is not known, check the relationship for `room_id` and `servers`. If + - When walking the thread DAG, if there is an event that is not known, check the relationship for `relationship_room_id` and `relationship_servers`. If they exist, peek into the room ([MSC2444](https://github.com/matrix-org/matrix-doc/pull/2444)), or if that is not supported, join the room as the user querying `/relationships` if and only if `"auto_join": true` in the `/relationships` request. This is required in order to allow the event to be retrieved. Server implementations can treat the auto join as the same as if the client made a request to [/join/{roomIdOrAlias}](https://matrix.org/docs/spec/client_server/r0.6.0#post-matrix-client-r0-join-roomidoralias) - with the `server_name` query parameters set to those in `servers`. + with the `server_name` query parameters set to those in `relationship_servers`. Security considerations: - Allowing cross-room threading leaks the event IDs in a given room, as well as which servers are in the room at the point @@ -206,3 +208,5 @@ Justifications: information *somewhere* so servers can retrieve the event and continue navigating the thread. As the client and server already have the event which contains a relationship to another event inside an unknown room, the simplest option is to also contain the routing information with that relationship. + - The fields are in the `unsigned` section so clients cannot artificially set them, and because `unsigned` is where a lot + of other server-calculated metadata resides.