From fd9d57b8c47980ac7931c029bffac87f9181843c Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Fri, 4 Sep 2020 14:38:29 +0100 Subject: [PATCH] Match state events sent to a remote server when inviting a user --- proposals/2403-knock.md | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/proposals/2403-knock.md b/proposals/2403-knock.md index 5317a1eab..424270187 100644 --- a/proposals/2403-knock.md +++ b/proposals/2403-knock.md @@ -142,23 +142,19 @@ value is a mapping from room ID to room information. The room information is a mapping from a key `knock_state` to another mapping with key `events` being a list of `StrippedStateEvent`. `StrippedStateEvent`s are defined as state events that only contain the `sender`, `type`, `state_key` and `content` -keys. This behaviour matches `invite_events` which already exists to provide -information to the client their current room invites. +keys. These stripped state events contain information about the room, most notably the room's name and avatar. A client will need this information to show a -nice representation of pending knocked rooms. Only `m.room.name`, -`m.room.avatar`, `m.room.join_rules` and `m.room.membership` state events -should be included here, rather than all room state event types. -Additionally, only `m.room.membership` events of the knocking user should be -included. +nice representation of pending knocked rooms. The recommended events to +include are the join rules, canonical alias, avatar, and name of the room, +rather than all room state. This behaviour matches the information sent to +remote servers when invited their users to a room. This prevents unneeded state from the room leaking out, and also speeds things up (think not sending over hundreds of membership events from big rooms). -XXX: Is `m.room.canonical_alias` worth allowing here for any reason? - The following is an example of knock state coming down `/sync`. Request: