From e93a19f62d95ac0b64e3b6d2944d1fc04304032d Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Wed, 2 Sep 2020 12:07:42 +0100 Subject: [PATCH] Indicate that this proposal requires a new room version --- proposals/2403-knock.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/proposals/2403-knock.md b/proposals/2403-knock.md index 926561a1..576e4808 100644 --- a/proposals/2403-knock.md +++ b/proposals/2403-knock.md @@ -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