Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-02-19 12:33:43 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Clarify implications of signing events.

Browse source
This commit is contained in:
Patrick Cloke 2021-06-28 09:02:19 -04:00 committed by Richard van der Hoff
parent 750be83313
commit 75fc073bfc
1 changed files with 12 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -69,7 +69,18 @@ caveat that servers must ensure that:
* The user's previous membership was `invite` or `join`, or * The user's previous membership was `invite` or `join`, or
* The `m.room.member` event with a `membership` of `join` has a valid signature * The `m.room.member` event with a `membership` of `join` has a valid signature
from a homeserver whose users have the power to issue invites. from a homeserver whose users have the power to issue invites. This implies
that:
* A join event issued via `/make_join` & `/send_join` is signed by the not
just the requesting server, but also the resident server. (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.)
* 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.
As normal, the above check is also performed against the current room state during As normal, the above check is also performed against the current room state during
[soft-failure](https://matrix.org/docs/spec/server_server/r0.1.4#soft-failure), [soft-failure](https://matrix.org/docs/spec/server_server/r0.1.4#soft-failure),