Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-02-04 05:13:42 +01:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Move client recommendations into its own section

Browse source 
Hopefully leading to less duplication in recommendations as well
This commit is contained in:
Andrew Morgan 2020-08-27 14:59:11 +01:00
parent aad6ff4a05
commit f3fc5399fc
1 changed files with 12 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
proposals/2403-knock.md
View file

@ -20,13 +20,7 @@ room. An example for the membership would look like the following:
}
```
After a knock is received in a room, it is expected to be displayed in the
timeline, similar to other membership changes. It is recommended to not
display the reason until the user interacts with the client in some way (e.g.
clicking on a "show reason" button), as else this would essentially allow
outsiders to send messages into the room. Clients can optionally add a way
for users of a room to review all current knocks. After a knock in a room, a
member of the room can invite the knocker.
After a knock in a room, a member of the room can invite the knocker.
To be able to implement this properly, two new endpoints need to be added:
one in the Client-Server API and one in the Server-Server API.
@ -255,11 +249,20 @@ and one to work properly over federation (`/join/{roomIdOrAlias}`). They
could both be merged into one, however, as that would also affect the join
endpoint it seems out-of-scope for this MSC.
# Client UX recommendations
After a knock is received in a room, it is expected to be displayed in the
timeline, similar to other membership changes. Clients can optionally add a way
for users of a room to review all current knocks.
# Security considerations
Clients must take care when implementing this feature in order to prevent
simple abuse vectors that can be accomplished by individual users. For
instance, When a knock occurs, client are advised to hide the reason by
default, prompting the user to reveal it only if they choose to.
instance, when a knock occurs, clients are advised to hide the reason until
the user interacts with the client in some way (e.g. clicking on a "show
reason" button). The user should reveal the reason only if they choose to.
It is recommended to not display the reason by default as else this would
essentially allow outsiders to send messages into the room.
It is still theoretically possible for a server admin to create many users
with different user IDs or display names, all spelling out an abusive