|
|
|
@ -37,6 +37,9 @@ must be set to "knock" for a knock to succeed. This means that existing rooms
|
|
|
|
|
will need to opt into allowing knocks in their rooms. Other than allowing
|
|
|
|
|
knocks, "knock" is no different from the "invite" join rule.
|
|
|
|
|
|
|
|
|
|
As we're updating the join rules, and thus the auth rules, this proposal will
|
|
|
|
|
need to be introduced as part of a new room version.
|
|
|
|
|
|
|
|
|
|
## Membership changes
|
|
|
|
|
Once someone has sent a `knock` membership into the room, the membership for
|
|
|
|
|
that user can be transitioned to the following possible states:
|
|
|
|
@ -237,6 +240,11 @@ If they deny, then a leave membership event is sent in the room, and the
|
|
|
|
|
knocking user will be notified through existing flows (matching the behaviour
|
|
|
|
|
of when an invite is recinded).
|
|
|
|
|
|
|
|
|
|
TODO: Federation passing certain needed state events from the server that has
|
|
|
|
|
the room to the server that's knocking. Can we filter the events sent over so
|
|
|
|
|
that we can avoid the security issue with invites that we found earlier? (And
|
|
|
|
|
then backport this filter to invites? :)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Server-Server API
|
|
|
|
|
Similarly to join and leave over federation, a ping-pong game with two new
|
|
|
|
|