Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-22 11:24:08 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Some clarifications and wording fixes

Browse source
This commit is contained in:
Andrew Morgan 2020-10-05 17:09:33 +01:00
parent 6f7bcb6052
commit 525d1d33e0
1 changed files with 30 additions and 23 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

53
proposals/2403-knock.md
View file

@ -20,10 +20,12 @@ room. An example for the membership would look like the following:
} }
``` ```
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, or they
can decide to reject it instead.
## Restrictions ## Restrictions
There are restrictions to being able to set this membership. There are restrictions to being able to set this membership, as well as
accepting or denying the knock.
### Current membership ### Current membership
Only users without a current membership or with their current membership Only users without a current membership or with their current membership
@ -37,11 +39,11 @@ 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 the join rules are moedified, the auth rules are as well. The [current As the join rules are modified, the auth rules are as well. The [current auth
auth rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) are rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) are defined
defined by each room version. Thus, to change these rules, implementation of by each room version. To change these rules, the implementation of this
this proposal must be done in a new room version. The explicit changes to the proposal must be done in a new room version. The explicit changes to the auth
auth rules from room version 5 are: rules from room version 5 are:
* Under "5. If type is `m.room.member`", the following should be added: * Under "5. If type is `m.room.member`", the following should be added:
@ -54,7 +56,7 @@ auth rules from room version 5 are:
v. Otherwise, reject. v. Otherwise, reject.
``` ```
Notes: Note that:
- a.ii is justified as it doesn't make sense for a user that is already - a.ii is justified as it doesn't make sense for a user that is already
in the room to knock. in the room to knock.
- a.iii is justified as an event should be rejected if it was sent by - a.iii is justified as an event should be rejected if it was sent by
@ -62,10 +64,9 @@ auth rules from room version 5 are:
homserver that's in the room, rather than the homeserver knocking). homserver that's in the room, rather than the homeserver knocking).
- a.iv is justified as knocks should be allowed if the knocking user has - a.iv is justified as knocks should be allowed if the knocking user has
been banned from the room, or they're already in the room. been banned from the room, or they're already in the room.
- Knocks are not restricted by power level like invites are. The `join_rules`
are already used to enforce whether someone can or cannot knock.
XXX: Is it a problem that any homeserver in the room can send a knock
event in? Even if they don't have the power level to send any other
events?
* Under "11. If type is `m.room.redaction`", the following should be added: * Under "11. If type is `m.room.redaction`", the following should be added:
@ -74,9 +75,9 @@ auth rules from room version 5 are:
``` ```
Notes: Notes:
- It seems bad if the server you sent a knock through later redacts that - The server you sent a knock through later should not be able to redact
knock, hence adding this. Ideally the knock should just be rejected that knock afterwards. The knock should instead be rejected by whoever
instead. has the authority to.
XXX: Is this the best place in the auth rules to enforce this? XXX: Is this the best place in the auth rules to enforce this?
@ -94,11 +95,12 @@ Let's talk about each one of these in more detail.
### Membership change to `invite` ### Membership change to `invite`
The knock has been accepted by someone. The knock has been accepted by someone in the room.
This user must have the power level to perform invites. The user's homeserver
will then send an invite - over federation if necessary - to the knocking The user who is accepting the knock must have the power level to perform
user. The knocking user may then join the room as if they had been invited invites. The user's homeserver will then send an invite - over federation if
normally. necessary - to the knocking user. The knocking user may then join the room as
if they had been invited normally.
The accept a knock, the client should call [`POST The accept a knock, the client should call [`POST
/_matrix/client/r0/rooms/{roomId}/invite`](https://matrix.org/docs/spec/client_server/r0.6.1#post-matrix-client-r0-rooms-roomid-invite) /_matrix/client/r0/rooms/{roomId}/invite`](https://matrix.org/docs/spec/client_server/r0.6.1#post-matrix-client-r0-rooms-roomid-invite)
@ -107,7 +109,7 @@ with the user ID of the knocking user in the JSON body.
If the knocking user is on another homeserver, then the homeserver of the If the knocking user is on another homeserver, then the homeserver of the
accepting user will call [`PUT accepting user will call [`PUT
/_matrix/federation/v2/invite/{roomId}/{eventId}`](https://matrix.org/docs/spec/server_server/r0.1.4#put-matrix-federation-v2-invite-roomid-eventid) /_matrix/federation/v2/invite/{roomId}/{eventId}`](https://matrix.org/docs/spec/server_server/r0.1.4#put-matrix-federation-v2-invite-roomid-eventid)
on the knocking homeserver to inform it that its knock has been accepted. on the knocking homeserver to inform it that the knock has been accepted.
The knocking homeserver should assume an invite to a room it has knocked on means The knocking homeserver should assume an invite to a room it has knocked on means
that its knock has been accepted, even if the invite was not explicitly that its knock has been accepted, even if the invite was not explicitly
@ -117,7 +119,6 @@ related to the knock attempt.
The knock has been rejected by someone in the room. The knock has been rejected by someone in the room.
XXX: There is also an open question here about who should be able to reject a XXX: There is also an open question here about who should be able to reject a
knock. When revoking an invite for a user, perhaps counter-intuitively, you knock. When revoking an invite for a user, perhaps counter-intuitively, you
need to have a high enough power level to kick users, rather than invite need to have a high enough power level to kick users, rather than invite
@ -151,7 +152,9 @@ if it is sent by the homeserver we originally knocked through. We know this
homeserver is (or at least was) in the room, so they're probably telling the homeserver is (or at least was) in the room, so they're probably telling the
truth. This is almost an edge case though, as while you'll knock through one truth. This is almost an edge case though, as while you'll knock through one
homeserver in the room, there's no guarantee that the admin that denies your homeserver in the room, there's no guarantee that the admin that denies your
knock will be on the same homeserver you knocked through. Perhaps the homeserver you knocked through could listen for this and then send the event back to you - but what if it goes offline in the meantime? knock will be on the same homeserver you knocked through. Perhaps the
homeserver you knocked through could listen for this and then send the event
back to you - but what if it goes offline in the meantime?
As such, this feature working over federation is de-scoped for now, and left As such, this feature working over federation is de-scoped for now, and left
to a future MSC which can solve this problem across the board for all to a future MSC which can solve this problem across the board for all
@ -162,7 +165,8 @@ they have access to the events it references.
### Membership change to `ban` ### Membership change to `ban`
The knock has been rejected by someone. The knock has been rejected by someone in the room and the user has been
banned, and is unable to send further knocks.
This one is fairly straightforward. Someone with the appropriate power levels This one is fairly straightforward. Someone with the appropriate power levels
in the room bans the user. This will have the same effect as rejecting the in the room bans the user. This will have the same effect as rejecting the
@ -174,6 +178,9 @@ If the user is unbanned, then knocks will be accepted again.
To ban the user, the client should call [`POST To ban the user, the client should call [`POST
/_matrix/client/r0/rooms/{roomId}/ban`](https://matrix.org/docs/spec/client_server/r0.6.1#post-matrix-client-r0-rooms-roomid-ban) with the user ID of the knocking user in the JSON body. /_matrix/client/r0/rooms/{roomId}/ban`](https://matrix.org/docs/spec/client_server/r0.6.1#post-matrix-client-r0-rooms-roomid-ban) with the user ID of the knocking user in the JSON body.
Informing the knocking user about the update is the same as rejecting the
knock.
## Client-Server API ## Client-Server API
Two new endpoints are introduced in the Client-Server API (similarly to Two new endpoints are introduced in the Client-Server API (similarly to