Indicate that this proposal requires a new room version

pull/977/head
Andrew Morgan 4 years ago
parent ae8ec6603c
commit e93a19f62d

@ -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 will need to opt into allowing knocks in their rooms. Other than allowing
knocks, "knock" is no different from the "invite" join rule. 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 ## Membership changes
Once someone has sent a `knock` membership into the room, the membership for Once someone has sent a `knock` membership into the room, the membership for
that user can be transitioned to the following possible states: 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 knocking user will be notified through existing flows (matching the behaviour
of when an invite is recinded). 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 ## Server-Server API
Similarly to join and leave over federation, a ping-pong game with two new Similarly to join and leave over federation, a ping-pong game with two new

Loading…
Cancel
Save