mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-01-02 14:08:38 +01:00
Some clarifications and wording fixes
This commit is contained in:
Andrew Morgan
parent
6f7bcb6052
commit
525d1d33e0
|
|
@ -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
|
||||
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
|
||||
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
|
||||
knocks, "knock" is no different from the "invite" join rule.
|
||||
|
||||
As the join rules are moedified, the auth rules are as well. The [current
|
||||
auth rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) are
|
||||
defined by each room version. Thus, to change these rules, implementation of
|
||||
this proposal must be done in a new room version. The explicit changes to the
|
||||
auth rules from room version 5 are:
|
||||
As the join rules are modified, the auth rules are as well. The [current auth
|
||||
rules](https://matrix.org/docs/spec/rooms/v1#authorization-rules) 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 should be added:
|
||||
|
||||
|
|
@ -54,7 +56,7 @@ auth rules from room version 5 are:
|
|||
v. Otherwise, reject.
|
||||
```
|
||||
|
||||
Notes:
|
||||
Note that:
|
||||
- a.ii is justified as it doesn't make sense for a user that is already
|
||||
in the room to knock.
|
||||
- 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).
|
||||
- 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.
|
||||
- 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:
|
||||
|
||||
|
|
@ -74,9 +75,9 @@ auth rules from room version 5 are:
|
|||
```
|
||||
|
||||
Notes:
|
||||
- It seems bad if the server you sent a knock through later redacts that
|
||||
knock, hence adding this. Ideally the knock should just be rejected
|
||||
instead.
|
||||
- The server you sent a knock through later should not be able to redact
|
||||
that knock afterwards. The knock should instead be rejected by whoever
|
||||
has the authority to.
|
||||
|
||||
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`
|
||||
|
||||
The knock has been accepted by someone.
|
||||
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
|
||||
user. The knocking user may then join the room as if they had been invited
|
||||
normally.
|
||||
The knock has been accepted by someone in the room.
|
||||
|
||||
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
|
||||
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
|
||||
/_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
|
||||
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)
|
||||
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
|
||||
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.
|
||||
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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`
|
||||
|
||||
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
|
||||
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
|
||||
/_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
|
||||
Two new endpoints are introduced in the Client-Server API (similarly to
|
||||
|
|
|
|||
Loading…
Reference in a new issue