wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Updates from review.

Browse source
This commit is contained in:
Patrick Cloke 2021-07-16 13:03:49 -04:00 • committed by Richard van der Hoff
parent 248cb8b310
commit 2bc4e86cb4
1 changed files with 21 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

33
proposals/3083-restricted-rooms.md
View file

@ -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.<sup id="a3">[3](#f3)</sup>
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).<sup id="a4">[4](#f4)</sup>
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.