Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-01-23 15:53:43 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Federation knock_room_state and minor cleanup

Browse source
This commit is contained in:
Andrew Morgan 2020-08-28 13:56:09 +01:00
parent ae8ec6603c
commit 5bfd65c59f
1 changed files with 53 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

67
proposals/2403-knock.md
View file

@ -61,7 +61,7 @@ join): `POST /_matrix/client/r0/rooms/{roomId}/knock` and `POST
/_matrix/client/r0/knock/{roomIdOrAlias}`. These allow the client to state /_matrix/client/r0/knock/{roomIdOrAlias}`. These allow the client to state
their intent to knock on a room. their intent to knock on a room.
Additionally, additions to the `GET /_matrix/client/r0/sync` endpoint are Additionally, extensions to the `GET /_matrix/client/r0/sync` endpoint are
introduced. These allow a client to receive information about the status of introduced. These allow a client to receive information about the status of
their knock attempt. their knock attempt.
@ -70,7 +70,7 @@ The path parameter (`roomId`) is the room on which you want to knock. It is
required. The post body accepts an optional string parameter, `reason`, which required. The post body accepts an optional string parameter, `reason`, which
is the reason you want to join the room. A request could look as follows: is the reason you want to join the room. A request could look as follows:
``` ```json
POST /_matrix/client/r0/rooms/%21d41d8cd%3Amatrix.org/knock HTTP/1.1 POST /_matrix/client/r0/rooms/%21d41d8cd%3Amatrix.org/knock HTTP/1.1
Content-Type: application/json Content-Type: application/json
@ -121,7 +121,7 @@ can be specified via the query parameters. The post body accepts an optional
string parameter, `reason`, which is the reason you want to join the room. A string parameter, `reason`, which is the reason you want to join the room. A
request could look as follows: request could look as follows:
``` ```json
POST /_matrix/client/r0/knock/%23foxes%3Amatrix.org?server_name=matrix.org&server_name=elsewhere.ca HTTP/1.1 POST /_matrix/client/r0/knock/%23foxes%3Amatrix.org?server_name=matrix.org&server_name=elsewhere.ca HTTP/1.1
Content-Type: application/json Content-Type: application/json
@ -180,7 +180,7 @@ Response:
"knock": { "knock": {
"!abcdefghijklmo:example.com": { "!abcdefghijklmo:example.com": {
"knock_state": { "knock_state": {
events: [ "events": [
{ {
"content": { "content": {
"join_rule": "knock" "join_rule": "knock"
@ -211,14 +211,9 @@ Response:
"displayname": "Knocking User", "displayname": "Knocking User",
"membership": "knock" "membership": "knock"
}, },
"origin_server_ts": 1598548763903,
"sender": "@knocking_user:example.org", "sender": "@knocking_user:example.org",
"state_key": "@knocking_user:example.org", "state_key": "@knocking_user:example.org",
"type": "m.room.member", "type": "m.room.member",
"unsigned": {
"age": 5
},
"event_id": "$12345"
} }
] ]
} }
@ -313,10 +308,10 @@ Response Format:
| Parameter | Type | Description | | Parameter | Type | Description |
|-----------|------|-------------| |-----------|------|-------------|
| `<body>` | Empty Object | | `knock_room_state` | [StrippedStateEvent] | Required. State events providing public room metadata
A request could look as follows: A request could look as follows:
``` ```json
PUT /_matrix/federation/v1/send_knock/%21abc123%3Amatrix.org/%24abc123%3Aexample.org HTTP/1.1 PUT /_matrix/federation/v1/send_knock/%21abc123%3Amatrix.org/%24abc123%3Aexample.org HTTP/1.1
Content-Type: application/json Content-Type: application/json
@ -338,9 +333,53 @@ Content-Type: application/json
#### Response: #### Response:
##### Status code 200: ##### Status code 200:
The event was successfully accepted into the graph by the receiving The event was successfully accepted into the graph by the receiving
homeserver. homeserver. The response contains `StrippedStateEvent`s with room metadata
(room name, avatar ...) that the knocking homeserver can pass to the client.
The event types that can be sent here should match those of the `/sync`
extensions mentioned above.
This is loosely based off of the
[federated invite](https://matrix.org/docs/spec/server_server/r0.1.4#put-matrix-federation-v2-invite-roomid-eventid)
request content.
```json ```json
{} {
"knock_room_state": [
{
"content": {
"join_rule": "knock"
},
"sender": "@room_admin:example.com",
"state_key": "",
"type": "m.room.join_rules"
},
{
"content": {
"name": "Some cool room"
},
"sender": "@room_admin:example.com",
"state_key": "",
"type": "m.room.name"
},
{
"content": {
"url": "mxc://example.com/xyz54321"
},
"sender": "@room_admin:example.com",
"state_key": "",
"type": "m.room.avatar"
},
{
"content": {
"avatar_url": "mxc://example.org/abc1234",
"displayname": "Knocking User",
"membership": "knock"
},
"sender": "@knocking_user:example.org",
"state_key": "@knocking_user:example.org",
"type": "m.room.member",
}
]
}
``` ```
# Potential issues # Potential issues
@ -373,4 +412,4 @@ essentially allow outsiders to send messages into the room.
It is still theoretically possible for a server admin to create many users 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 with different user IDs or display names, all spelling out an abusive
message, and then having each of them knock in order. In this case, room message, and then having each of them knock in order. In this case, room
admins should employ typical abuse mitigation tools, such as Server ACLs. admins should employ typical abuse mitigation tools, such as Server ACLs.