wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Apply suggestions from code review

Browse source 
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
This commit is contained in:
Andrew Morgan 2021-02-24 18:45:11 +00:00 • committed by GitHub
parent 24f61c283c
commit e790ad2120
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 17 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

32
proposals/2403-knock.md
View file

@ -9,7 +9,7 @@ This proposal implements the reserved "knock" membership type for the
knocks on a room, they are asking for permission to join. Like all membership knocks on a room, they are asking for permission to join. Like all membership
events, it contains an optional "reason" parameter to specify the reason you events, it contains an optional "reason" parameter to specify the reason you
want to join. Like other membership types, the parameters "displayname" and want to join. Like other membership types, the parameters "displayname" and
"avatar_url" are optional. This membership can be set from users who aren't "avatar_url" are optional. This membership can be sent by users who aren't
currently in said room. An example for the membership would look like the currently in said room. An example for the membership would look like the
following: following:
```json ```json
@ -26,7 +26,8 @@ can decide to reject it instead.
## Restrictions ## Restrictions
There are restrictions to being able to set this membership, as well as There are restrictions to being able to set this membership, as well as
accepting or denying the knock. accepting or denying the knock. A formal description of the changes to the auth rules is given below;
first we summarise the semantics of the proposed changes.
### 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
@ -42,16 +43,17 @@ knocks, a join rule of "knock" is functionally equivalent to that of
"invite", except that it additionally allows external users to change their "invite", except that it additionally allows external users to change their
membership to "knock" under certain conditions. membership to "knock" under certain conditions.
As the join rules are modified, the auth rules are as well. The [current auth
rules](https://matrix.org/docs/spec/rooms/v6#authorization-rules-for-events) are defined
by each room version. To change these rules, the implementation of this
proposal must be done in a new room version. The explicit changes to the auth
rules from room version 5 are:
* Under "5. If type is `m.room.member`", the following will be added: ### Auth rules
Each room version defines the auth rules which should be applied in that room version.
This MSC proposes a new room version with the following changes to the [auth
rules from room version 6](https://matrix.org/docs/spec/rooms/v6#authorization-rules-for-events):
* Under "5. If type is `m.room.member`", insert the following after "e. If membership is `ban`":
``` ```
a. If `membership` is `knock`: f. If `membership` is `knock`:
i. If the `join_rule` is anything other than `knock`, reject. i. If the `join_rule` is anything other than `knock`, reject.
ii. If `sender` does not match `state_key`, reject. ii. If `sender` does not match `state_key`, reject.
iii. If the `sender`'s membership is not `ban`, `knock`, `invite` or `join`, allow. iii. If the `sender`'s membership is not `ban`, `knock`, `invite` or `join`, allow.
@ -59,12 +61,10 @@ rules from room version 5 are:
``` ```
Note that: Note that:
- The `sender` field in the event is set to the user ID of the knocking - Both the `sender` and `state_key` fields are set to the user ID of the knocking
user, not any other user in the room that belongs to a homeserver that user. This is different to an `invite` membership event, where the `sender` is the inviter and
the knocking user is using to inject into the room DAG. This is separate
from an invite membership event, where the `sender` is the inviter and
the `state_key` is the invitee. the `state_key` is the invitee.
- a.ii is justified as one user should not be able to knock on behalf of - f.ii is justified as one user should not be able to knock on behalf of
another user. another user.
- a.iii is justified as knocks should not be allowed if the knocking user - a.iii is justified as knocks should not be allowed if the knocking user
has been banned from the room, has already knocked on the room, is has been banned from the room, has already knocked on the room, is
@ -95,7 +95,7 @@ Let's talk about each one of these in more detail.
The knock has been accepted by someone in the room. The knock has been accepted by someone in the room.
The user who is accepting the knock must have the power level to perform The user who is accepting the knock must have the power level to perform
invites. The user's homeserver will then send an invite - over federation if invites. The accepting user's homeserver will then send an invite - over federation if
necessary - to the knocking user. The knocking user may then join the room as necessary - to the knocking user. The knocking user may then join the room as
if they had been invited normally. if they had been invited normally.
@ -146,7 +146,7 @@ validate the `prev_events` and `auth_events` that the event references. We
could send those events over as well, but those will also reference other could send those events over as well, but those will also reference other
events that require validation and so on. events that require validation and so on.
A dumb thing we could easily do here is to trust the leave event implicitly A simple thing we could easily do here is to trust the leave event implicitly
if it is sent by the homeserver we originally knocked through. We know this 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