From 2bc4e86cb48f9e6d59e94380d9da288179287833 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Fri, 16 Jul 2021 13:03:49 -0400 Subject: [PATCH] Updates from review. --- proposals/3083-restricted-rooms.md | 33 +++++++++++++++++++----------- 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/proposals/3083-restricted-rooms.md b/proposals/3083-restricted-rooms.md index 89103c0d..063251d9 100644 --- a/proposals/3083-restricted-rooms.md +++ b/proposals/3083-restricted-rooms.md @@ -72,6 +72,8 @@ join, as above. The requesting server may wish to attempt to join via another homeserver. If no servers are in any of the allowed rooms its membership cannot be verified (and this is a misconfiguration). +TODO Better define errors over federation. + From the perspective of the [auth rules](https://spec.matrix.org/unstable/rooms/v1/#authorization-rules), the `restricted` join rule has the same behavior as `public`, with the additional caveat that servers must ensure that: @@ -85,35 +87,39 @@ caveat that servers must ensure that: server, but also the resident server.[3](#f3) In order for the joining server to receive the proper signatures the join - event will be returned via `/send_join` in the `join_event` field. + event will be returned via `/send_join` in the `event` field. * The auth chain of the join event needs to include an event which proves the homeserver can be issuing the join. This can be done by including the `m.room.power_levels` event and an `m.room.member` event with `membership` equal to `join` for a member who could issue invites from that server. In order to find a corresponding event quickly for verification, the - content of the join event should include the other user's MXID in the - content with the key `join_authorised_via_users_server`. + content of the join event should include the chosen user's MXID in the + content with the key `join_authorised_via_users_server`. The actual user + chosen is arbitrary. Note that the homeservers whose users can issue invites are trusted to confirm that the `allow` rules were properly checked (since this cannot easily be enforced over federation by event authorisation).[4](#f4) +To better cope with joining via aliases, homeservers should use the list of +authorised servers (not the list of candidate servers) when a user attempts to +join a room. + ## Summary of the behaviour of join rules See the [join rules](https://matrix.org/docs/spec/client_server/r0.6.1#m-room-join-rules) specification for full details; the summary below is meant to highlight the differences -between `public`, `invite`, and `restricted`. Note that all join rules are subject -to `ban` and `server_acls`. +between `public`, `invite`, and `restricted` from a user perspective. Note that +all join rules are subject to `ban` and `server_acls`. * `public`: anyone can join, as today. * `invite`: only people with membership `invite` can join, as today. * `knock`: the same as `invite`, except anyone can knock. See [MSC2403](https://github.com/matrix-org/matrix-doc/pull/2403). * `private`: This is reserved, but unspecified. -* `restricted`: the same as `public`, with the additional caveat that servers must - verify the `m.room.member` event is signed by a homeserver whose users may issue - invites if the joining member was not previously invited or joined into the room. +* `restricted`: the same as `invite`, except users may also join if they are a + member of a room listed in the `allow` rules. ## Security considerations @@ -214,7 +220,7 @@ restricting access via: These are just examples are not fully thought through for this MSC, but it should be possible to add these behaviors in the future. -### Interaction with `m.space.child` events +### Client considerations [MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772) defines a `via` key in the content of `m.space.child` events: @@ -222,13 +228,16 @@ key in the content of `m.space.child` events: > the content must contain a via `key` which gives a list of candidate servers > that can be used to join the room. -It is possible for the candidate servers and the list of authorised servers to -not be in sync. In the case where there's no overlap between these lists, it may -not be possible for a server to complete the request. +It is possible for the list of candidate servers and the list of authorised +servers to diverge. It may not be possible for a user to join a room if there's +no overlap between these lists. If there is some overlap between the lists of servers the join request should complete successfully. +Clients should also consider the authorised servers when generating candidate +servers to embed in links to the room, e.g. via matrix.to. + A future MSC may define a way to override or update the `via` key in a coherent manner.