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

Add note about including the authorising server in the content.

Browse source
This commit is contained in:
Patrick Cloke 2021-07-13 12:59:43 -04:00 • committed by Richard van der Hoff
parent c42e89a4d4
commit 72f564c236
1 changed files with 13 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -82,18 +82,19 @@ caveat that servers must ensure that:
that: that:
* A join event issued via `/make_join` & `/send_join` is signed by not * A join event issued via `/make_join` & `/send_join` is signed by not
just the requesting server, but also the resident server. (This seems like just the requesting server, but also the resident server.<sup id="a3">[3](#f3)</sup>
an improvement regardless since the resident server is accepting the event
on behalf of the joining server and ideally this should be verifiable after
the fact, even for current room versions.)
* The auth chain of the join event needs to include an event which proves * 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 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` `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. 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`.
Note that the homeservers whose users can issue invites are trusted to confirm 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 that the `allow` rules were properly checked (since this cannot easily be
enforced over federation by event authorisation).<sup id="a3">[3](#f3)</sup> enforced over federation by event authorisation).<sup id="a4">[4](#f4)</sup>
## Summary of the behaviour of join rules ## Summary of the behaviour of join rules
@ -242,8 +243,13 @@ receiving invites in `public` rooms today, and they work as you might expect.
The only difference is that you are not *required* to hold an invite when The only difference is that you are not *required* to hold an invite when
joining the room. [↩](#a2) joining the room. [↩](#a2)
<a id="f3"/>[3]: This has the downside of increased centralisation, as some <a id="f3"/>[3]: This seems like an improvement regardless since the resident server
is accepting the event on behalf of the joining server and ideally this should be
verifiable after the fact, even for current room versions. Requiring all events
to be signed and verified in this way is left to a future MSC. [↩](#a3)
<a id="f4"/>[4]: This has the downside of increased centralisation, as some
homeservers that are already in the room may not issue a join event for another homeservers that are already in the room may not issue a join event for another
user on that server. (It must go through the `/make_join` / `/send_join` flow of user on that server. (It must go through the `/make_join` / `/send_join` flow of
a server whose users may issue invites.) This is considered a reasonable a server whose users may issue invites.) This is considered a reasonable
trade-off. [↩](#a3) trade-off. [↩](#a4)