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

Merge branch 'main' into exclude-non-cross-signed

Browse source
This commit is contained in:
Richard van der Hoff 2026-02-24 14:38:11 +00:00 committed by GitHub
parent 2fca4789ca 57a1d5ad0e
commit 1e9ba77bb7
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
50 changed files with 950 additions and 157 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
changelogs/appendices/newsfragments/2307.clarification Normal file
View file

@ -0,0 +1 @@
Add identifier pronunciation guidelines. Contributed by @HarHarLinks.

1
changelogs/client_server/newsfragments/2278.feature Normal file
View file

@ -0,0 +1 @@
Add administrator endpoints to lock and suspend server-local users and add the `m.account_management` capability, as per [MSC4323](https://github.com/matrix-org/matrix-spec-proposals/pull/4323).

1
changelogs/client_server/newsfragments/2278.new.1 Normal file
View file

@ -0,0 +1 @@
Add `GET /_matrix/client/v1/admin/suspend/{userId}`, as per [MSC4323](https://github.com/matrix-org/matrix-spec-proposals/pull/4323).

1
changelogs/client_server/newsfragments/2278.new.2 Normal file
View file

@ -0,0 +1 @@
Add `PUT /_matrix/client/v1/admin/suspend/{userId}`, as per [MSC4323](https://github.com/matrix-org/matrix-spec-proposals/pull/4323).

1
changelogs/client_server/newsfragments/2278.new.3 Normal file
View file

@ -0,0 +1 @@
Add `GET /_matrix/client/v1/admin/lock/{userId}`, as per [MSC4323](https://github.com/matrix-org/matrix-spec-proposals/pull/4323).

1
changelogs/client_server/newsfragments/2278.new.4 Normal file
View file

@ -0,0 +1 @@
Add `PUT /_matrix/client/v1/admin/lock/{userId}`, as per [MSC4323](https://github.com/matrix-org/matrix-spec-proposals/pull/4323).

1
changelogs/client_server/newsfragments/2292.feature Normal file
View file

@ -0,0 +1 @@
Add `m.forget_forced_upon_leave` capability for servers to transparently auto-forget rooms that the user leaves as per [MSC4267](https://github.com/matrix-org/matrix-spec-proposals/pull/4267).

1
changelogs/client_server/newsfragments/2298.feature Normal file
View file

@ -0,0 +1 @@
Add support for `m.room.redaction` events at the `PUT /rooms/{roomId}/send/{eventType}/{txnId}` endpoint, as per [MSC4169](https://github.com/matrix-org/matrix-spec-proposals/pull/4169).

1
changelogs/client_server/newsfragments/2299.feature Normal file
View file

@ -0,0 +1 @@
Clients supporting the `ol` HTML element must also support the `start` attribute, as per [MSC4313](https://github.com/matrix-org/matrix-spec-proposals/pull/4313).

1
changelogs/client_server/newsfragments/2304.clarification Normal file
View file

@ -0,0 +1 @@
Clarify the requiredness of `event_id` in `predecessor`.

1
changelogs/client_server/newsfragments/2305.feature Normal file
View file

@ -0,0 +1 @@
Add invite blocking, as per [MSC4380](https://github.com/matrix-org/matrix-spec-proposals/pull/4380).

1
changelogs/client_server/newsfragments/2306.clarification Normal file
View file

@ -0,0 +1 @@
Clarify terminology for keys in cross-signing module.

1
changelogs/internal/newsfragments/2317.clarification Normal file
View file

@ -0,0 +1 @@
Update the footer social links to match matrix.org. Contributed by @HarHarLinks.

1
changelogs/room_versions/newsfragments/2303.clarification Normal file
View file

@ -0,0 +1 @@
Remove the post-1.16 release note for room version 12.

1
changelogs/server_server/newsfragments/2191.clarification Normal file
View file

@ -0,0 +1 @@
Clarify what the `minimum_valid_until_ts` field means when it is set in key queries.

1
changelogs/server_server/newsfragments/2284.clarification Normal file
View file

@ -0,0 +1 @@
Specify validation for PDUs passed to and returned from federation membership endpoints.

1
changelogs/server_server/newsfragments/2300.clarification Normal file
View file

@ -0,0 +1 @@
Change `m.signing_update` typo to `m.signing_key_update`. Contributed by @velikopter

20
config/_default/hugo.toml
View file

@ -115,11 +115,6 @@ sidebar_menu_compact = true
url = "https://gitlab.matrix.org/matrix-org" url = "https://gitlab.matrix.org/matrix-org"
icon = "fab fa-gitlab" icon = "fab fa-gitlab"
desc = "Matrix on GitLab" desc = "Matrix on GitLab"
[[params.links.bottom]]
name = "YouTube"
url = "https://www.youtube.com/channel/UCVFkW-chclhuyYRbmmfwt6w"
icon = "fab fa-youtube"
desc = "Matrix YouTube channel"
[[params.links.bottom]] [[params.links.bottom]]
name = "Mastodon" name = "Mastodon"
url = "https://mastodon.matrix.org/@matrix" url = "https://mastodon.matrix.org/@matrix"
@ -130,6 +125,21 @@ sidebar_menu_compact = true
url = "https://bsky.app/profile/matrix.org" url = "https://bsky.app/profile/matrix.org"
icon = "fab fa-bluesky" icon = "fab fa-bluesky"
desc = "Matrix on Bluesky" desc = "Matrix on Bluesky"
[[params.links.bottom]]
name = "LinkedIn"
url = "https://www.linkedin.com/company/matrix-org/"
icon = "fab fa-linkedin"
desc = "Matrix on LinkedIn"
[[params.links.bottom]]
name = "YouTube"
url = "https://www.youtube.com/channel/UCVFkW-chclhuyYRbmmfwt6w"
icon = "fab fa-youtube"
desc = "Matrix YouTube channel"
[[params.links.bottom]]
name = "Matrix.org Blog Feed"
url = "https://matrix.org/atom.xml"
icon = "fas fa-rss"
desc = "Matrix.org Blog Atom Feed"
# configuration for the hugo development server # configuration for the hugo development server

5
content/appendices.md
View file

@ -533,6 +533,11 @@ where `domain` is the [server name](#server-name) of the homeserver
which allocated the identifier, and `localpart` is an identifier which allocated the identifier, and `localpart` is an identifier
allocated by that homeserver. allocated by that homeserver.
Because the domain part identifies the server on which the ID resolves,
the canonical pronunciation of the separating `:` is "on".
For example, `@user:matrix.org` would be pronounced as "at user on matrix dot
org".
The precise grammar defining the allowable format of an identifier The precise grammar defining the allowable format of an identifier
depends on the type of identifier. For example, event IDs can sometimes depends on the type of identifier. For example, event IDs can sometimes
be represented with a `domain` component under some conditions - see the be represented with a `domain` component under some conditions - see the

61
content/client-server-api/_index.md
View file

@ -2394,9 +2394,12 @@ where feasible. The Matrix-specific actions are:
Server administrators may apply locks to prevent users from usefully Server administrators may apply locks to prevent users from usefully
using their accounts, for instance, due to safety or security concerns. using their accounts, for instance, due to safety or security concerns.
In contrast to account deactivation, locking is a non-destructive action In contrast to account deactivation, locking is a non-destructive action
that can be reversed. This specification describes the behaviour of clients that can be reversed.
and servers when an account is locked. It deliberately leaves the methods
for locking and unlocking accounts as a server implementation detail. {{% added-in v="1.18" %}} To lock or unlock an account, administrators
SHOULD use the [`PUT /admin/lock/{userId}`](#put_matrixclientv1adminlockuserid)
endpoint. They MAY also use [`GET /admin/lock/{userId}`](#get_matrixclientv1adminlockuserid)
to check whether a user's account is locked.
When an account is locked, servers MUST return a `401 Unauthorized` error When an account is locked, servers MUST return a `401 Unauthorized` error
response with an `M_USER_LOCKED` error code and [`soft_logout`](#soft-logout) response with an `M_USER_LOCKED` error code and [`soft_logout`](#soft-logout)
@ -2445,6 +2448,11 @@ from that account. The effect is similar to [locking](#account-locking), though
without risk of the client losing state from a logout. Suspensions are reversible, without risk of the client losing state from a logout. Suspensions are reversible,
like locks and unlike deactivations. like locks and unlike deactivations.
{{% added-in v="1.18" %}} To suspend or unsuspend an account, administrators
SHOULD use the [`PUT /admin/suspend/{userId}`](#put_matrixclientv1adminsuspenduserid)
endpoint. They MAY also use [`GET /admin/suspend/{userId}`](#get_matrixclientv1adminsuspenduserid)
to check whether a user's account is suspended.
The actions a user can perform while suspended is deliberately left as an The actions a user can perform while suspended is deliberately left as an
implementation detail. Servers SHOULD permit the user to perform at least the implementation detail. Servers SHOULD permit the user to perform at least the
following, however: following, however:
@ -2500,9 +2508,6 @@ Content-Type: application/json
} }
``` ```
APIs for initiating suspension or unsuspension are not included in this version
of the specification, and left as an implementation detail.
### Adding Account Administrative Contact Information ### Adding Account Administrative Contact Information
A homeserver may keep some contact information for administrative use. A homeserver may keep some contact information for administrative use.
@ -2619,6 +2624,40 @@ An example of the capability API's response for this capability is:
} }
``` ```
### `m.forget_forced_upon_leave` capability
{{% added-in v="1.18" %}}
This capability has a single flag, `enabled`, which indicates whether or
not the server automatically forgets rooms which the user has left.
When `enabled` is `true` and the user leaves a room, the server will automatically
forget the room — just as if the user had called [`/forget`](#post_matrixclientv3roomsroomidforget)
themselves. This behavior applies irrespective of whether the user has left the
room on their own (through [`/leave`](#post_matrixclientv3roomsroomidleave)) or
has been kicked or banned from the room by another user.
When `enabled` is `false`, the server does not automatically forget rooms
upon leave. In this case, clients MAY distinguish the actions of leaving
and forgetting a room in their UI. Similarly, clients MAY retrieve and
visualize left but unforgotten rooms using a [filter](#filtering) with
`include_leave = true`.
When the capability or the `enabled` property are not present, clients SHOULD
assume that the server does not automatically forget rooms.
An example of the capability API's response for this capability is:
```json
{
"capabilities": {
"m.forget_forced_upon_leave": {
"enabled": true
}
}
}
```
### `m.room_versions` capability ### `m.room_versions` capability
This capability describes the default and available room versions a This capability describes the default and available room versions a
@ -3315,6 +3354,14 @@ the topic to be removed from the room.
#### Client behaviour #### Client behaviour
{{% changed-in v="1.18" %}}
If the server advertises support for a spec version that supports it, clients
MAY use the [`PUT /rooms/{roomId}/send/{eventType}/{txnId}`](#put_matrixclientv3roomsroomidsendeventtypetxnid)
endpoint to send `m.room.redaction` events in all room versions.
They can also use the following endpoint.
{{% http-api spec="client-server" api="redaction" %}} {{% http-api spec="client-server" api="redaction" %}}
### Forming relationships between events ### Forming relationships between events
@ -4029,6 +4076,7 @@ that profile.
| [Sticker Messages](#sticker-messages) | Optional | Optional | Optional | Optional | Optional | | [Sticker Messages](#sticker-messages) | Optional | Optional | Optional | Optional | Optional |
| [Third-party Networks](#third-party-networks) | Optional | Optional | Optional | Optional | Optional | | [Third-party Networks](#third-party-networks) | Optional | Optional | Optional | Optional | Optional |
| [Threading](#threading) | Optional | Optional | Optional | Optional | Optional | | [Threading](#threading) | Optional | Optional | Optional | Optional | Optional |
| [Invite permission](#invite-permission) | Optional | Optional | Optional | Optional | Optional |
*Please see each module for more details on what clients need to *Please see each module for more details on what clients need to
implement.* implement.*
@ -4102,6 +4150,7 @@ systems.
{{% cs-module name="SSO client login/authentication" filename="sso_login" %}} {{% cs-module name="SSO client login/authentication" filename="sso_login" %}}
{{% cs-module name="Direct Messaging" filename="dm" %}} {{% cs-module name="Direct Messaging" filename="dm" %}}
{{% cs-module name="Ignoring Users" filename="ignore_users" %}} {{% cs-module name="Ignoring Users" filename="ignore_users" %}}
{{% cs-module name="Invite permission" filename="invite_permission" %}}
{{% cs-module name="Sticker Messages" filename="stickers" %}} {{% cs-module name="Sticker Messages" filename="stickers" %}}
{{% cs-module name="Reporting Content" filename="report_content" %}} {{% cs-module name="Reporting Content" filename="report_content" %}}
{{% cs-module name="Third-party Networks" filename="third_party_networks" %}} {{% cs-module name="Third-party Networks" filename="third_party_networks" %}}

102
content/client-server-api/modules/end_to_end_encryption.md
View file

@ -178,7 +178,7 @@ Example:
``` ```
`ed25519` and `curve25519` keys are used for [device keys](#device-keys). `ed25519` and `curve25519` keys are used for [device keys](#device-keys).
Additionally, `ed25519` keys are used for [cross-signing keys](#cross-signing). Additionally, `ed25519` keys are used for [cross-signing](#cross-signing).
`signed_curve25519` keys are used for [one-time and fallback keys](#one-time-and-fallback-keys). `signed_curve25519` keys are used for [one-time and fallback keys](#one-time-and-fallback-keys).
@ -760,8 +760,8 @@ The process between Alice and Bob verifying each other would be:
15. Assuming they match, Alice and Bob's devices each calculate Message 15. Assuming they match, Alice and Bob's devices each calculate Message
Authentication Codes (MACs) for: Authentication Codes (MACs) for:
* {{% changed-in v="1.18" %}} Each of the keys that they wish the other user * {{% changed-in v="1.18" %}} Each of the keys that they wish the other user
to verify (usually their device ed25519 key and their master cross-signing to verify (usually their device ed25519 key and their master signing key,
key). The master cross-signing key SHOULD be included when two different see below). The master signing key SHOULD be included when two different
users are verifying each other. Verifying individual devices of other users are verifying each other. Verifying individual devices of other
users is deprecated. users is deprecated.
* The complete list of key IDs that they wish the other user to verify. * The complete list of key IDs that they wish the other user to verify.
@ -1019,40 +1019,42 @@ and can be translated online:
Rather than requiring Alice to verify each of Bob's devices with each of Rather than requiring Alice to verify each of Bob's devices with each of
her own devices and vice versa, the cross-signing feature allows users her own devices and vice versa, the cross-signing feature allows users
to sign their device keys such that Alice and Bob only need to verify to sign their device keys such that Alice and Bob only need to verify
once. With cross-signing, each user has a set of cross-signing keys that once. With cross-signing, each user has a set of cross-signing key pairs that
are used to sign their own device keys and other users' keys, and can be are used to sign their own device keys and other users' keys, and can be
used to trust device keys that were not verified directly. used to trust device keys that were not verified directly.
Each user has three ed25519 key pairs for cross-signing: Each user has three ed25519 key pairs used for cross-signing (cross-signing keys):
- a master key (MSK) that serves as the user's identity in - a master signing key (MSK, for historical reasons sometimes known as
cross-signing and signs their other cross-signing keys; `master_key`) that serves as the user's identity in cross-signing and signs
their user-signing and self-signing keys;
- a user-signing key (USK) -- only visible to the user that it belongs - a user-signing key (USK) -- only visible to the user that it belongs
to --that signs other users' master keys; and to -- that signs other users' master signing keys; and
- a self-signing key (SSK) that signs the user's own device keys. - a self-signing key (SSK) that signs the user's own device keys.
The master key may also be used to sign other items such as the backup The master signing key may also be used to sign other items such as the backup
key. The master key may also be signed by the user's own device keys to key. The master signing key may also be signed by the user's own device keys to
aid in migrating from device verifications: if Alice's device had aid in migrating from device verifications: if Alice's device had
previously verified Bob's device and Bob's device has signed his master previously verified Bob's device and Bob's device has signed his master
key, then Alice's device can trust Bob's master key, and she can sign it key, then Alice's device can trust Bob's master signing key, and she can sign it
with her user-signing key. with her user-signing key.
Users upload their cross-signing keys to the server using [POST Users upload the public parts of their master signing, user-signing and
self-signing keys to the server using [POST
/\_matrix/client/v3/keys/device\_signing/upload](/client-server-api/#post_matrixclientv3keysdevice_signingupload). When Alice uploads /\_matrix/client/v3/keys/device\_signing/upload](/client-server-api/#post_matrixclientv3keysdevice_signingupload). When Alice uploads
new cross-signing keys, her user ID will appear in the `changed` new keys, her user ID will appear in the `changed`
property of the `device_lists` field of the `/sync` of response of all property of the `device_lists` field of the `/sync` of response of all
users who share an encrypted room with her. When Bob sees Alice's user users who share an encrypted room with her. When Bob sees Alice's user
ID in his `/sync`, he will call [POST /\_matrix/client/v3/keys/query](/client-server-api/#post_matrixclientv3keysquery) ID in his `/sync`, he will call [POST /\_matrix/client/v3/keys/query](/client-server-api/#post_matrixclientv3keysquery)
to retrieve Alice's device and cross-signing keys. to retrieve Alice's device keys, as well as their cross-signing keys.
If Alice has a device and wishes to send an encrypted message to Bob, If Alice has a device and wishes to send an encrypted message to Bob,
she can trust Bob's device if: she can trust Bob's device if:
- Alice's device is using a master key that has signed her - Alice's device is using a master signing key that has signed her
user-signing key, user-signing key,
- Alice's user-signing key has signed Bob's master key, - Alice's user-signing key has signed Bob's master signing key,
- Bob's master key has signed Bob's self-signing key, and - Bob's master signing key has signed Bob's self-signing key, and
- Bob's self-signing key has signed Bob's device key. - Bob's self-signing key has signed Bob's device key.
The following diagram illustrates how keys are signed: The following diagram illustrates how keys are signed:
@ -1112,27 +1114,28 @@ signatures that she cannot see:
``` ```
[Verification methods](#device-verification) can be used to verify a [Verification methods](#device-verification) can be used to verify a
user's master key by using the master public key, encoded using unpadded user's master signing key by treating its public key (master signing public
base64, as the device ID, and treating it as a normal device. For key), encoded using unpadded base64, as the device ID, and treating it as a
example, if Alice and Bob verify each other using SAS, Alice's normal device. For example, if Alice and Bob verify each other using SAS,
Alice's
`m.key.verification.mac` message to Bob may include `m.key.verification.mac` message to Bob may include
`"ed25519:alices+master+public+key": "alices+master+public+key"` in the `"ed25519:alices+master+public+key": "alices+master+public+key"` in the
`mac` property. Servers therefore must ensure that device IDs will not `mac` property. Servers therefore must ensure that device IDs will not
collide with cross-signing public keys. collide with cross-signing public keys.
The cross-signing private keys can be stored on the server or shared with other Using the [Secrets](#secrets) module the private parts of the cross-signing keys can
devices using the [Secrets](#secrets) module. When doing so, the master, be stored on the server or shared with other devices. When doing so, the
user-signing, and self-signing keys are identified using the names master signing, user-signing, and self-signing keys are identified using the
`m.cross_signing.master`, `m.cross_signing.user_signing`, and names `m.cross_signing.master`, `m.cross_signing.user_signing`, and
`m.cross_signing.self_signing`, respectively, and the keys are base64-encoded `m.cross_signing.self_signing`, respectively, and the keys are base64-encoded
before being encrypted. before being encrypted.
###### Key and signature security ###### Key and signature security
A user's master key could allow an attacker to impersonate that user to A user's master signing key could allow an attacker to impersonate that user to
other users, or other users to that user. Thus clients must ensure that other users, or other users to that user. Thus clients must ensure that
the private part of the master key is treated securely. If clients do the private part of the master signing key is treated securely. If clients do
not have a secure means of storing the master key (such as a secret not have a secure means of storing the master signing key (such as a secret
storage system provided by the operating system), then clients must not storage system provided by the operating system), then clients must not
store the private part. store the private part.
@ -1145,9 +1148,9 @@ Since device key IDs (`ed25519:DEVICE_ID`) and cross-signing key IDs
use the correct keys when verifying. use the correct keys when verifying.
While servers MUST not allow devices to have the same IDs as cross-signing While servers MUST not allow devices to have the same IDs as cross-signing
keys, a malicious server could construct such a situation, so clients must not keys, a malicious server could construct such a situation, so clients
rely on the server being well-behaved and should take the following precautions must not rely on the server being well-behaved and should take the following
against this. precautions against this:
1. Clients MUST refer to keys by their public keys during the verification 1. Clients MUST refer to keys by their public keys during the verification
process, rather than only by the key ID. process, rather than only by the key ID.
@ -1155,31 +1158,32 @@ against this.
verification process, and ensure that they do not change in the course of verification process, and ensure that they do not change in the course of
verification. verification.
3. Clients SHOULD also display a warning and MUST refuse to verify a user when 3. Clients SHOULD also display a warning and MUST refuse to verify a user when
they detect that the user has a device with the same ID as a cross-signing key. they detect that the user has a device with the same ID as a cross-signing
key.
A user's user-signing and self-signing keys are intended to be easily A user's user-signing and self-signing keys are intended to be easily
replaceable if they are compromised by re-issuing a new key signed by replaceable if they are compromised by re-issuing a new key signed by
the user's master key and possibly by re-verifying devices or users. the user's master signing key and possibly by re-verifying devices or users.
However, doing so relies on the user being able to notice when their However, doing so relies on the user being able to notice when their
keys have been compromised, and it involves extra work for the user, and keys have been compromised, and it involves extra work for the user, and
so although clients do not have to treat the private parts as so although clients do not have to treat the private parts as
sensitively as the master key, clients should still make efforts to sensitively as the master signing key, clients should still make efforts to
store the private part securely, or not store it at all. Clients will store the private part securely, or not store it at all. Clients will
need to balance the security of the keys with the usability of signing need to balance the security of the keys with the usability of signing
users and devices when performing key verification. users and devices when performing key verification.
To avoid leaking of social graphs, servers will only allow users to see: To avoid leaking of social graphs, servers will only allow users to see:
- signatures made by the user's own master, self-signing or - signatures made by the user's own master signing, self-signing or
user-signing keys, user-signing keys,
- signatures made by the user's own devices about their own master - signatures made by the user's own devices about their own master
key, key,
- signatures made by other users' self-signing keys about their - signatures made by other users' self-signing keys about their
respective devices, respective devices,
- signatures made by other users' master keys about their respective - signatures made by other users' master signing keys about their respective
self-signing key, or self-signing key, or
- signatures made by other users' devices about their respective - signatures made by other users' devices about their respective
master keys. master signing keys.
Users will not be able to see signatures made by other users' Users will not be able to see signatures made by other users'
user-signing keys. user-signing keys.
@ -1281,24 +1285,24 @@ The binary segment MUST be of the following form:
- one byte indicating the QR code verification mode. Should be one of the - one byte indicating the QR code verification mode. Should be one of the
following values: following values:
- `0x00` verifying another user with cross-signing - `0x00` verifying another user with cross-signing
- `0x01` self-verifying in which the current device does trust the master key - `0x01` self-verifying in which the current device does trust the master signing key
- `0x02` self-verifying in which the current device does not yet trust the - `0x02` self-verifying in which the current device does not yet trust the
master key master signing key
- the event ID or `transaction_id` of the associated verification - the event ID or `transaction_id` of the associated verification
request event, encoded as: request event, encoded as:
- two bytes in network byte order (big-endian) indicating the length in - two bytes in network byte order (big-endian) indicating the length in
bytes of the ID as a UTF-8 string bytes of the ID as a UTF-8 string
- the ID encoded as a UTF-8 string - the ID encoded as a UTF-8 string
- the first key, as 32 bytes. The key to use depends on the mode field: - the first key, as 32 bytes. The key to use depends on the mode field:
- if `0x00` or `0x01`, then the current user's own master cross-signing public key - if `0x00` or `0x01`, then the current user's own master signing public key
- if `0x02`, then the current device's Ed25519 signing key - if `0x02`, then the current device's Ed25519 signing key
- the second key, as 32 bytes. The key to use depends on the mode field: - the second key, as 32 bytes. The key to use depends on the mode field:
- if `0x00`, then what the device thinks the other user's master - if `0x00`, then what the device thinks the other user's master
cross-signing public key is public key is
- if `0x01`, then what the device thinks the other device's Ed25519 signing - if `0x01`, then what the device thinks the other device's Ed25519 signing
public key is public key is
- if `0x02`, then what the device thinks the user's master cross-signing public - if `0x02`, then what the device thinks the user's master signing public key
key is is
- a random shared secret, as a sequence of bytes. It is suggested to use a secret - a random shared secret, as a sequence of bytes. It is suggested to use a secret
that is about 8 bytes long. Note: as we do not share the length of the that is about 8 bytes long. Note: as we do not share the length of the
secret, and it is not a fixed size, clients will just use the remainder of secret, and it is not a fixed size, clients will just use the remainder of
@ -1309,14 +1313,14 @@ For example, if Alice displays a QR code encoding the following binary data:
```nohighlight ```nohighlight
"MATRIX" |ver|mode| len | event ID "MATRIX" |ver|mode| len | event ID
4D 41 54 52 49 58 02 00 00 2D 21 41 42 43 44 ... 4D 41 54 52 49 58 02 00 00 2D 21 41 42 43 44 ...
| user's cross-signing key | other user's cross-signing key | shared secret | the first key | the second key | shared secret
00 01 02 03 04 05 06 07 ... 10 11 12 13 14 15 16 17 ... 20 21 22 23 24 25 26 27 00 01 02 03 04 05 06 07 ... 10 11 12 13 14 15 16 17 ... 20 21 22 23 24 25 26 27
``` ```
this indicates that Alice is verifying another user (say Bob), in response to Mode `0x00` indicates that Alice is verifying another user (say Bob), in
the request from event "$ABCD...", her cross-signing key is response to the request from event "$ABCD...", her master signing key is
`0001020304050607...` (which is "AAECAwQFBg..." in base64), she thinks that `0001020304050607...` (which is "AAECAwQFBg..." in base64), she thinks that
Bob's cross-signing key is `1011121314151617...` (which is "EBESExQVFh..." in Bob's master signing key is `1011121314151617...` (which is "EBESExQVFh..." in
base64), and the shared secret is `2021222324252627` (which is "ICEiIyQlJic" in base64), and the shared secret is `2021222324252627` (which is "ICEiIyQlJic" in
base64). base64).
@ -1388,8 +1392,8 @@ one of its variants.
Clients must only store keys in backups after they have ensured that the Clients must only store keys in backups after they have ensured that the
`auth_data` is trusted. This can be done either by: `auth_data` is trusted. This can be done either by:
- checking that it is signed by the user's [master cross-signing - checking that it is signed by the user's [master signing key](#cross-signing)
key](#cross-signing) or by a verified device belonging to the same user, or or by a verified device belonging to the same user, or
- deriving the public key from a private key that it obtained from a trusted - deriving the public key from a private key that it obtained from a trusted
source. Trusted sources for the private key include the user entering the source. Trusted sources for the private key include the user entering the
key, retrieving the key stored in [secret storage](#secret-storage), or key, retrieving the key stored in [secret storage](#secret-storage), or

4
content/client-server-api/modules/instant_messaging.md
View file

@ -84,6 +84,10 @@ Additionally, web clients should ensure that *all* `a` tags get a
`rel="noopener"` to prevent the target page from referencing the `rel="noopener"` to prevent the target page from referencing the
client's tab/window. client's tab/window.
{{% added-in v="1.18" %}} Clients that support rendering numbered lists via the
`ol` tag MUST also support the `start` attribute in order to prevent loss of
meaning of a message due to the numbering of list items.
Tags must not be nested more than 100 levels deep. Clients should only Tags must not be nested more than 100 levels deep. Clients should only
support the subset of tags they can render, falling back to other support the subset of tags they can render, falling back to other
representations of the tags where possible. For example, a client may representations of the tags where possible. For example, a client may

51
content/client-server-api/modules/invite_permission.md Normal file
View file

@ -0,0 +1,51 @@
### Invite permission
{{% added-in v="1.18" %}}
Users may want to control who is allowed to invite them to new rooms. This module defines how
clients and servers can implement invite permission.
#### Account data
{{% event event="m.invite_permission_config" %}}
#### Client behaviour
To reject invites from all users automatically, clients MAY add an [`m.invite_permission_config`](#minvite_permission_config)
event in the user's [account data](#client-config) with the `default_action` property set to
`block`. To stop rejecting all invites, the same event without the `default_action` property MUST be
added to the account data.
When the `default_action` field is unset, other parts of the specification might still have effects
on invites seen by clients, like [ignoring users](#ignoring-users).
Attempting to send an invite to a user that blocks invites will result in an error response with the
`M_INVITE_BLOCKED` error code.
#### Server behaviour
When invites to a given user are blocked, the user's homeserver MUST respond to the following
endpoints with an HTTP 403 status code, with the Matrix error code `M_INVITE_BLOCKED`, if the user
is invited:
* [`PUT /_matrix/federation/v1/invite/{roomId}/{eventId}`](/server-server-api/#put_matrixfederationv1inviteroomideventid)
* [`PUT /_matrix/federation/v2/invite/{roomId}/{eventId}`](/server-server-api/#put_matrixfederationv2inviteroomideventid)
* [`POST /_matrix/client/v3/rooms/{roomId}/invite`](#post_matrixclientv3roomsroomidinvite)
* [`POST /_matrix/client/v3/createRoom`](#post_matrixclientv3createroom), due to a user in the
`invite` list. It is possible for one of the invited users to be rejected whilst the room creation
as a whole succeeds.
* [`PUT /_matrix/client/v3/rooms/{roomId}/state/m.room.member/{stateKey}`](#put_matrixclientv3roomsroomidstateeventtypestatekey),
when the `membership` is set to `invite`.
In addition, invite events for this user already in the database, or received over federation, MUST
NOT be served over client synchronisation endpoints such as [`GET /sync`](#get_matrixclientv3sync).
Servers MAY return any suppressed invite events over `GET /sync` if invite blocking is later
disabled.
Other endpoints, such as [`GET /rooms/{roomId}/state`](#get_matrixclientv3roomsroomidstate), are not
affected by invite blocking: invite events are returned as normal.
The Application Services API is also unaffected by invite blocking: invite events are sent over
[`PUT /_matrix/app/v1/transactions/{txnId}`](/application-service-api/#put_matrixappv1transactionstxnid).

4
content/client-server-api/modules/room_upgrades.md
View file

@ -43,8 +43,8 @@ They must be explicitly set during the `/upgrade` call.
{{% /boxes/note %}} {{% /boxes/note %}}
{{% boxes/note %}} {{% boxes/note %}}
{{% added-in v="1.16" %}} When upgrading to room version 12 or later, the `predecessor` field MAY NOT contain {{% added-in v="1.16" %}} When upgrading to room version 12 or later, the `event_id` property inside
an `event_id`. `predecessor` MAY be omitted.
{{% /boxes/note %}} {{% /boxes/note %}}
3. Replicates transferable state events to the new room. The exact 3. Replicates transferable state events to the new room. The exact

13
content/rooms/_index.md
View file

@ -56,19 +56,6 @@ Clients should not ask room administrators to upgrade their rooms if the
room is running a stable version. Servers SHOULD use **room version 12** as room is running a stable version. Servers SHOULD use **room version 12** as
the default room version when creating new rooms. the default room version when creating new rooms.
{{% boxes/note %}}
{{% added-in v="1.16" %}}
Room version 12 is introduced and made default in this specification release.
Servers are encouraged to continue using room version 11 as the default room
version for the early days and weeks following this specification release,
and then gradually switch the default over when they deem appropriate.
<!-- TODO(SCT): Remove this note box in Matrix 1.17 -->
{{% /boxes/note %}}
The available room versions are: The available room versions are:
- [Version 1](/rooms/v1) - **Stable**. The initial room version. - [Version 1](/rooms/v1) - **Stable**. The initial room version.

6
content/server-server-api.md
View file

@ -868,8 +868,10 @@ selecting a resident from the candidate list, and using the
enough information for the joining server to fill in the event. enough information for the joining server to fill in the event.
The joining server is expected to add or replace the `origin`, The joining server is expected to add or replace the `origin`,
`origin_server_ts`, and `event_id` on the templated event received by `origin_server_ts`, and `event_id` on the templated event received by the
the resident server. This event is then signed by the joining server. resident server. The joining server MUST also verify that the `type`, `room_id`,
`sender`, `state_key` and `content.membership` fields have the expected values.
This event is then signed by the joining server.
To complete the join handshake, the joining server submits this new event To complete the join handshake, the joining server submits this new event
to the resident server it used for `GET /make_join`, using the `PUT /send_join` to the resident server it used for `GET /make_join`, using the `PUT /send_join`

389
data/api/client-server/admin.yaml
View file

@ -16,7 +16,7 @@ info:
title: Matrix Client-Server Administration API title: Matrix Client-Server Administration API
version: 1.0.0 version: 1.0.0
paths: paths:
"/admin/whois/{userId}": "/v3/admin/whois/{userId}":
get: get:
summary: Gets information about a particular user. summary: Gets information about a particular user.
description: |- description: |-
@ -107,6 +107,391 @@ paths:
} }
tags: tags:
- Server administration - Server administration
"/v1/admin/suspend/{userId}":
get:
summary: Gets information about the suspended status of a particular user.
x-addedInMatrixVersion: "1.18"
description: |-
Gets information about the suspended status of a particular server-local user.
The user calling this endpoint MUST be a server admin.
In order to prevent user enumeration, servers MUST ensure that authorization is checked
prior to trying to do account lookups.
operationId: getAdminSuspendUser
security:
- accessTokenQuery: []
- accessTokenBearer: []
parameters:
- in: path
name: userId
description: The user to look up.
required: true
example: "@peter:rabbit.rocks"
schema:
type: string
format: mx-user-id
pattern: "^@"
responses:
"200":
description: The lookup was successful.
content:
application/json:
schema:
type: object
properties:
suspended:
type: boolean
description: Whether the target account is suspended.
example: true
required:
- suspended
examples:
response:
value: {
"suspended": true,
}
"400":
description: |-
The user ID does not belong to the local server. The errcode is `M_INVALID_PARAM`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_INVALID_PARAM",
"error": "User does not belong to the local server."
}
"403":
description: |-
The requesting user is not a server administrator, or the target user is another
administrator. The errcode is `M_FORBIDDEN`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_FORBIDDEN",
"error": "Requesting user is not a server administrator."
}
"404":
description: |-
The user ID is not found, or is deactivated. The errcode is `M_NOT_FOUND`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_NOT_FOUND",
"error": "User not found."
}
tags:
- Server administration
put:
summary: Set the suspended status of a particular user.
x-addedInMatrixVersion: "1.18"
description: |-
Sets the suspended status of a particular server-local user.
The user calling this endpoint MUST be a server admin. The client SHOULD check that the user
is allowed to suspend other users at the [`GET /capabilities`](/client-server-api/#get_matrixclientv3capabilities)
endpoint prior to using this endpoint.
In order to prevent user enumeration, servers MUST ensure that authorization is checked
prior to trying to do account lookups.
operationId: setAdminSuspendUser
security:
- accessTokenQuery: []
- accessTokenBearer: []
parameters:
- in: path
name: userId
description: The user to change the suspended status of.
required: true
example: "@peter:rabbit.rocks"
schema:
type: string
format: mx-user-id
pattern: "^@"
requestBody:
content:
application/json:
schema:
type: object
properties:
suspended:
type: boolean
description: Whether to suspend the target account.
example: true
required:
- suspended
examples:
request:
value: {
"suspended": true,
}
required: true
responses:
"200":
description: The action was successful.
content:
application/json:
schema:
type: object
properties:
suspended:
type: boolean
description: Whether the target account is suspended.
example: true
required:
- suspended
examples:
response:
value: {
"suspended": true,
}
"400":
description: |-
The user ID does not belong to the local server. The errcode is `M_INVALID_PARAM`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_INVALID_PARAM",
"error": "User does not belong to the local server."
}
"403":
description: |-
The requesting user is not a server administrator, is trying to suspend their own
account, or the target user is another administrator. The errcode is `M_FORBIDDEN`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_FORBIDDEN",
"error": "Requesting user is not a server administrator."
}
"404":
description: |-
The user ID is not found, or is deactivated. The errcode is `M_NOT_FOUND`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_NOT_FOUND",
"error": "User not found."
}
tags:
- Server administration
"/v1/admin/lock/{userId}":
get:
summary: Gets information about the locked status of a particular user.
x-addedInMatrixVersion: "1.18"
description: |-
Gets information about the locked status of a particular server-local user.
The user calling this endpoint MUST be a server admin.
In order to prevent user enumeration, servers MUST ensure that authorization is checked
prior to trying to do account lookups.
operationId: getAdminLockUser
security:
- accessTokenQuery: []
- accessTokenBearer: []
parameters:
- in: path
name: userId
description: The user to look up.
required: true
example: "@peter:rabbit.rocks"
schema:
type: string
format: mx-user-id
pattern: "^@"
responses:
"200":
description: The lookup was successful.
content:
application/json:
schema:
type: object
properties:
locked:
type: boolean
description: Whether the target account is locked.
required:
- locked
examples:
response:
value: {
"locked": true,
}
"400":
description: |-
The user ID does not belong to the local server. The errcode is `M_INVALID_PARAM`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_INVALID_PARAM",
"error": "User does not belong to the local server."
}
"403":
description: |-
The requesting user is not a server administrator, or the target user is another
administrator. The errcode is `M_FORBIDDEN`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_FORBIDDEN",
"error": "Requesting user is not a server administrator."
}
"404":
description: |-
The user ID is not found, or is deactivated. The errcode is `M_NOT_FOUND`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_NOT_FOUND",
"error": "User not found."
}
tags:
- Server administration
put:
summary: Set the locked status of a particular user.
x-addedInMatrixVersion: "1.18"
description: |-
Sets the locked status of a particular server-local user.
The user calling this endpoint MUST be a server admin. The client SHOULD check that the user
is allowed to lock other users at the [`GET /capabilities`](/client-server-api/#get_matrixclientv3capabilities)
endpoint prior to using this endpoint.
In order to prevent user enumeration, servers MUST ensure that authorization is checked
prior to trying to do account lookups.
operationId: setAdminLockUser
security:
- accessTokenQuery: []
- accessTokenBearer: []
parameters:
- in: path
name: userId
description: The user to change the locked status of.
required: true
example: "@peter:rabbit.rocks"
schema:
type: string
format: mx-user-id
pattern: "^@"
requestBody:
content:
application/json:
schema:
type: object
properties:
locked:
type: boolean
description: Whether to lock the target account.
example: true
required:
- locked
examples:
request:
value: {
"locked": true,
}
required: true
responses:
"200":
description: The action was successful.
content:
application/json:
schema:
type: object
properties:
locked:
type: boolean
description: Whether the target account is locked.
example: true
required:
- locked
examples:
response:
value: {
"locked": true,
}
"400":
description: |-
The user ID does not belong to the local server. The errcode is `M_INVALID_PARAM`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_INVALID_PARAM",
"error": "User does not belong to the local server."
}
"403":
description: |-
The requesting user is not a server administrator, is trying to lock their own
account, or the target user is another administrator. The errcode is `M_FORBIDDEN`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_FORBIDDEN",
"error": "Requesting user is not a server administrator."
}
"404":
description: |-
The user ID is not found, or is deactivated. The errcode is `M_NOT_FOUND`.
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_NOT_FOUND",
"error": "User not found."
}
tags:
- Server administration
servers: servers:
- url: "{protocol}://{hostname}{basePath}" - url: "{protocol}://{hostname}{basePath}"
variables: variables:
@ -118,7 +503,7 @@ servers:
hostname: hostname:
default: localhost:8008 default: localhost:8008
basePath: basePath:
default: /_matrix/client/v3 default: /_matrix/client
components: components:
securitySchemes: securitySchemes:
accessTokenQuery: accessTokenQuery:

40
data/api/client-server/capabilities.yaml
View file

@ -50,6 +50,12 @@ paths:
m.change_password: m.change_password:
$ref: '#/components/schemas/booleanCapability' $ref: '#/components/schemas/booleanCapability'
description: Capability to indicate if the user can change their password. description: Capability to indicate if the user can change their password.
m.forget_forced_upon_leave:
x-addedInMatrixVersion: "1.18"
$ref: '#/components/schemas/booleanCapability'
description: |-
Capability to indicate if the server automatically forgets rooms once the user
leaves.
m.room_versions: m.room_versions:
type: object type: object
description: The room versions the server supports. description: The room versions the server supports.
@ -78,7 +84,7 @@ paths:
description: | description: |
**Deprecated:** Capability to indicate if the user can change their display name. **Deprecated:** Capability to indicate if the user can change their display name.
Refer to `m.profile_fields` for extended profile management. Refer to `m.profile_fields` for extended profile management.
For backwards compatibility, servers that directly or indirectly include the For backwards compatibility, servers that directly or indirectly include the
`displayname` profile field in the `m.profile_fields` capability MUST also `displayname` profile field in the `m.profile_fields` capability MUST also
set this capability accordingly. set this capability accordingly.
@ -115,7 +121,7 @@ paths:
description: | description: |
If present, a list of profile fields that clients are allowed to create, modify or delete, If present, a list of profile fields that clients are allowed to create, modify or delete,
provided `enabled` is `true`; no other profile fields may be changed. provided `enabled` is `true`; no other profile fields may be changed.
If absent, clients may set all profile fields except those forbidden by the `disallowed` If absent, clients may set all profile fields except those forbidden by the `disallowed`
list, where present. list, where present.
items: items:
@ -127,7 +133,7 @@ paths:
type: array type: array
description: | description: |
This property has no meaning if `allowed` is also specified. This property has no meaning if `allowed` is also specified.
Otherwise, if present, a list of profile fields that clients are _not_ allowed to create, modify or delete. Otherwise, if present, a list of profile fields that clients are _not_ allowed to create, modify or delete.
Provided `enabled` is `true`, clients MAY assume that they can set any profile field which is not Provided `enabled` is `true`, clients MAY assume that they can set any profile field which is not
included in this list. included in this list.
@ -141,6 +147,34 @@ paths:
example: true example: true
required: required:
- enabled - enabled
m.account_moderation:
x-addedInMatrixVersion: "1.18"
type: object
title: AccountModerationCapability
description: |-
Capability to indicate if the user can perform account moderation actions
via [server administration](/client-server-api/#server-administration)
endpoints.
This property should be omitted altogether if `suspend` and `lock` would
be `false`.
properties:
suspend:
type: boolean
description: |-
`true` if the user can suspend a user via [`PUT /admin/suspend/{userId}`](/client-server-api/#put_matrixclientv1adminsuspenduserid),
`false` otherwise.
Defaults to `false`.
example: true
lock:
type: boolean
description: |-
`true` if the user can lock a user via [`PUT /admin/lock/{userId}`](/client-server-api/#put_matrixclientv1adminlockuserid),
`false` otherwise.
Defaults to `false`.
example: true
examples: examples:
response: response:
value: { value: {

12
data/api/client-server/create_room.yaml
View file

@ -250,7 +250,6 @@ paths:
} }
"400": "400":
description: |- description: |-
The request is invalid. A meaningful `errcode` and description The request is invalid. A meaningful `errcode` and description
error text will be returned. Example reasons for rejection include: error text will be returned. Example reasons for rejection include:
@ -274,6 +273,17 @@ paths:
application/json: application/json:
schema: schema:
$ref: definitions/errors/error.yaml $ref: definitions/errors/error.yaml
"403":
description: |-
Creating the room is not allowed.
{{% added-in v="1.18"%}} The `M_INVITE_BLOCKED` error code is used to
indicate that one of the homeservers of the invited users rejected
the invite due to [invite blocking](/client-server-api/#invite-permission).
content:
application/json:
schema:
$ref: definitions/errors/error.yaml
tags: tags:
- Room creation - Room creation
servers: servers:

18
data/api/client-server/cross_signing.yaml
View file

@ -32,9 +32,9 @@ paths:
except when used by an application service. except when used by an application service.
User-Interactive Authentication MUST be performed for regular clients, except in these cases: User-Interactive Authentication MUST be performed for regular clients, except in these cases:
- there is no existing cross-signing master key uploaded to the homeserver, OR - there is no existing master signing key uploaded to the homeserver, OR
- there is an existing cross-signing master key and it exactly matches the - there is an existing master signing key and it exactly matches the
cross-signing master key provided in the request body. If there are any additional master signing key provided in the request body. If there are any additional
keys provided in the request (self-signing key, user-signing key) they MUST also keys provided in the request (self-signing key, user-signing key) they MUST also
match the existing keys stored on the server. In other words, the request contains match the existing keys stored on the server. In other words, the request contains
no new keys. no new keys.
@ -61,22 +61,22 @@ paths:
type: object type: object
properties: properties:
master_key: master_key:
description: Optional. The user\'s master key. description: Optional. The user\'s master signing key.
allOf: allOf:
- $ref: definitions/cross_signing_key.yaml - $ref: definitions/cross_signing_key.yaml
self_signing_key: self_signing_key:
description: |- description: |-
Optional. The user\'s self-signing key. Must be signed by Optional. The user\'s self-signing key. Must be signed by
the accompanying master key, or by the user\'s most recently the accompanying master signing key, or by the user\'s most recently
uploaded master key if no master key is included in the uploaded master signing key if no master signing key is included in the
request. request.
allOf: allOf:
- $ref: definitions/cross_signing_key.yaml - $ref: definitions/cross_signing_key.yaml
user_signing_key: user_signing_key:
description: |- description: |-
Optional. The user\'s user-signing key. Must be signed by Optional. The user\'s user-signing key. Must be signed by
the accompanying master key, or by the user\'s most recently the accompanying master signing key, or by the user\'s most recently
uploaded master key if no master key is included in the uploaded master signing key if no master signing key is included in the
request. request.
allOf: allOf:
- $ref: definitions/cross_signing_key.yaml - $ref: definitions/cross_signing_key.yaml
@ -147,7 +147,7 @@ paths:
* `M_INVALID_SIGNATURE`: For example, the self-signing or * `M_INVALID_SIGNATURE`: For example, the self-signing or
user-signing key had an incorrect signature. user-signing key had an incorrect signature.
* `M_MISSING_PARAM`: No master key is available. * `M_MISSING_PARAM`: No master signing key is available.
content: content:
application/json: application/json:
schema: schema:

6
data/api/client-server/definitions/cross_signing_key.yaml
View file

@ -13,7 +13,7 @@
# limitations under the License. # limitations under the License.
type: object type: object
title: CrossSigningKey title: CrossSigningKey
description: Cross signing key description: Key used for cross signing
properties: properties:
user_id: user_id:
type: string type: string
@ -44,8 +44,8 @@ properties:
title: Signatures title: Signatures
description: |- description: |-
Signatures of the key, calculated using the process described at [Signing JSON](/appendices/#signing-json). Signatures of the key, calculated using the process described at [Signing JSON](/appendices/#signing-json).
Optional for the master key. Other keys must be signed by the Optional for the master signing key. Other keys must be signed by the
user\'s master key. user\'s master signing key.
example: { example: {
"@alice:example.com": { "@alice:example.com": {
"ed25519:alice+base64+master+key": "signature+of+key" "ed25519:alice+base64+master+key": "signature+of+key"

10
data/api/client-server/inviting.yaml
View file

@ -83,7 +83,7 @@ paths:
value: {} value: {}
"400": "400":
description: |- description: |-
The request is invalid. A meaningful `errcode` and description The request is invalid. A meaningful `errcode` and description
error text will be returned. Example reasons for rejection include: error text will be returned. Example reasons for rejection include:
@ -99,12 +99,18 @@ paths:
$ref: definitions/errors/error.yaml $ref: definitions/errors/error.yaml
"403": "403":
description: |- description: |-
You do not have permission to invite the user to the room. A meaningful `errcode` and description error text will be returned. Example reasons for rejections are: You do not have permission to invite the user to the room. A
meaningful `errcode` and description error text will be returned.
Example reasons for rejections are:
- The invitee has been banned from the room. - The invitee has been banned from the room.
- The invitee is already a member of the room. - The invitee is already a member of the room.
- The inviter is not currently in the room. - The inviter is not currently in the room.
- The inviter's power level is insufficient to invite users to the room. - The inviter's power level is insufficient to invite users to the room.
{{% added-in v="1.18"%}} The `M_INVITE_BLOCKED` error code is used to
indicate that the homeserver rejected the invite due to
[invite blocking](/client-server-api/#invite-permission).
content: content:
application/json: application/json:
schema: schema:

4
data/api/client-server/keys.yaml
View file

@ -219,8 +219,8 @@ paths:
x-addedInMatrixVersion: "1.1" x-addedInMatrixVersion: "1.1"
type: object type: object
description: |- description: |-
Information on the master cross-signing keys of the queried users. Information on the master signing keys of the queried users.
A map from user ID, to master key information. For each key, the A map from user ID, to master signing key information. For each key, the
information returned will be the same as uploaded via information returned will be the same as uploaded via
`/keys/device_signing/upload`, along with the signatures `/keys/device_signing/upload`, along with the signatures
uploaded via `/keys/signatures/upload` that the requesting user uploaded via `/keys/signatures/upload` that the requesting user

15
data/api/client-server/leaving.yaml
View file

@ -19,6 +19,10 @@ paths:
"/rooms/{roomId}/leave": "/rooms/{roomId}/leave":
post: post:
summary: Stop the requesting user participating in a particular room. summary: Stop the requesting user participating in a particular room.
x-changedInMatrixVersion:
"1.18": |-
Servers may additionally forget the room provided that they make this behavior
transparent.
description: |- description: |-
This API stops a user participating in a particular room. This API stops a user participating in a particular room.
@ -29,8 +33,15 @@ paths:
If the user was invited to the room, but had not joined, this call If the user was invited to the room, but had not joined, this call
serves to reject the invite. serves to reject the invite.
The user will still be allowed to retrieve history from the room which Servers MAY additionally forget the room when this endpoint is called –
they were previously allowed to see. just as if the user had also invoked [`/forget`](/client-server-api/#post_matrixclientv3roomsroomidforget).
Servers that do this, MUST inform clients about this behavior using the
[`m.forget_forced_upon_leave`](/client-server-api/#mforget_forced_upon_leave-capability)
capability.
If the server doesn't automatically forget the room, the user will still be
allowed to retrieve history from the room which they were previously allowed
to see.
operationId: leaveRoom operationId: leaveRoom
security: security:
- accessTokenQuery: [] - accessTokenQuery: []

9
data/api/client-server/room_send.yaml
View file

@ -20,6 +20,10 @@ paths:
"/rooms/{roomId}/send/{eventType}/{txnId}": "/rooms/{roomId}/send/{eventType}/{txnId}":
put: put:
summary: Send a message event to the given room. summary: Send a message event to the given room.
x-changedInMatrixVersion:
"1.18": |-
Homeservers must support sending `m.room.redaction` events with this endpoint
for all room versions.
description: |- description: |-
This endpoint is used to send a message event to a room. Message events This endpoint is used to send a message event to a room. Message events
allow access to historical events and pagination, making them suited allow access to historical events and pagination, making them suited
@ -28,6 +32,11 @@ paths:
The body of the request should be the content object of the event; the The body of the request should be the content object of the event; the
fields in this object will vary depending on the type of event. See fields in this object will vary depending on the type of event. See
[Room Events](/client-server-api/#room-events) for the m. event specification. [Room Events](/client-server-api/#room-events) for the m. event specification.
Homeservers MUST allow clients to send `m.room.redaction` events with this
endpoint for all room versions. In rooms with a version older than 11 they
MUST move the `redacts` property inside the `content` to the top level of
the event.
operationId: sendMessage operationId: sendMessage
security: security:
- accessTokenQuery: [] - accessTokenQuery: []

8
data/api/client-server/room_state.yaml
View file

@ -116,7 +116,13 @@ paths:
"error": "The alias '#hello:example.org' does not point to this room." "error": "The alias '#hello:example.org' does not point to this room."
} }
"403": "403":
description: The sender doesn't have permission to send the event into the room. description: |-
The sender doesn't have permission to send the event into the room.
{{% added-in v="1.18"%}} If the `eventType` is `m.room.member` and
the `membership` is `invite`, the `M_INVITE_BLOCKED` error code is
used to indicate that the homeserver rejected the invite due to
[invite blocking](/client-server-api/#invite-permission).
content: content:
application/json: application/json:
schema: schema:

4
data/api/client-server/third_party_membership.yaml
View file

@ -97,6 +97,10 @@ paths:
- The invitee is already a member of the room. - The invitee is already a member of the room.
- The inviter is not currently in the room. - The inviter is not currently in the room.
- The inviter's power level is insufficient to invite users to the room. - The inviter's power level is insufficient to invite users to the room.
{{% added-in v="1.18"%}} The `M_INVITE_BLOCKED` error code is used to
indicate that the homeserver rejected the invite due to
[invite blocking](/client-server-api/#invite-permission).
content: content:
application/json: application/json:
schema: schema:

2
data/api/server-server/definitions/event-schemas/m.signing_key_update.yaml
View file

@ -25,7 +25,7 @@ allOf:
edu_type: edu_type:
type: string type: string
enum: ['m.signing_key_update'] enum: ['m.signing_key_update']
description: The string `m.signing_update`. description: The string `m.signing_key_update`.
example: "m.signing_key_update" example: "m.signing_key_update"
content: content:
type: object type: object

53
data/api/server-server/invites-v1.yaml
View file

@ -36,6 +36,28 @@ paths:
Also note that if the remote homeserver is already in the room, it will receive the Also note that if the remote homeserver is already in the room, it will receive the
invite event twice; once through this endpoint, and again through a [federation invite event twice; once through this endpoint, and again through a [federation
transaction](/server-server-api/#transactions). transaction](/server-server-api/#transactions).
Servers MUST apply certain validation to ensure they don't accidentally sign non-invite
events from a malicious server. A specific error code is not mandated, but servers SHOULD
return `M_INVALID_PARAM` if:
* The invite event fails a [signature check](/server-server-api/#validating-hashes-and-signatures-on-received-events).
* The event type is not `m.room.member`.
* The `membership` field inside the event content is not `invite`.
* The event sender is not a user ID on the origin server.
* The `state_key` is not a user ID on the receiving server.
The `invite_room_state` has additional validation, which servers MAY apply to room versions
1 through 11 and SHOULD apply to all other room versions. As with the above errors, servers
SHOULD return `M_INVALID_PARAM` if:
* The `m.room.create` event is missing from `invite_room_state`.
* One or more entries in `invite_room_state` are not formatted according
to the room's version.
* One or more events fails a [signature check](/server-server-api/#validating-hashes-and-signatures-on-received-events).
* One or more events does not reside in the same room as the invite.
Note: Some room versions may require calculating the room ID for an
event rather than relying on the presence of `room_id`.
operationId: sendInviteV1 operationId: sendInviteV1
security: security:
- signedRequest: [] - signedRequest: []
@ -83,8 +105,7 @@ paths:
MUST additionally be formatted according to the room version specification. MUST additionally be formatted according to the room version specification.
Servers might need to apply validation to the `invite_room_state` depending Servers might need to apply validation to the `invite_room_state` depending
on room version. See the `400 M_MISSING_PARAM` error definition for more on room version. See endpoint description for more information.
information.
Note that events have a different format depending on the room Note that events have a different format depending on the room
version - check the [room version specification](/rooms) for version - check the [room version specification](/rooms) for
@ -155,11 +176,17 @@ paths:
] ]
"403": "403":
description: |- description: |-
The invite is not allowed. This could be for a number of reasons, including: The invite is not allowed.
The `M_FORBIDDEN` error code is used to indicate one of the following:
* The sender is not allowed to send invites to the target user/homeserver. * The sender is not allowed to send invites to the target user/homeserver.
* The homeserver does not permit anyone to invite its users. * The homeserver does not permit anyone to invite its users.
* The homeserver refuses to participate in the room. * The homeserver refuses to participate in the room.
{{% added-in v="1.18"%}} The `M_INVITE_BLOCKED` error code is used to
indicate that the homeserver rejected the invite due to
[invite blocking](/client-server-api/#invite-permission).
content: content:
application/json: application/json:
schema: schema:
@ -172,23 +199,7 @@ paths:
} }
"400": "400":
description: |- description: |-
The `M_MISSING_PARAM` error code is used to indicate one or more of The request is invalid in some way.
the following:
* The `m.room.create` event is missing from `invite_room_state`.
* One or more entries in `invite_room_state` are not formatted according
to the room's version.
* One or more events fails a [signature check](/server-server-api/#validating-hashes-and-signatures-on-received-events).
* One or more events does not reside in the same room as the invite.
Note: Some room versions may require calculating the room ID for an
event rather than relying on the presence of `room_id`.
Servers MAY apply the validation above to room versions 1 through 11,
and SHOULD apply the validation above to all other room versions.
If `M_MISSING_PARAM` is returned and the request is associated with a
Client-Server API request, the Client-Server API request SHOULD fail
with a 5xx error rather than being passed through.
content: content:
application/json: application/json:
schema: schema:
@ -196,7 +207,7 @@ paths:
examples: examples:
response: response:
value: { value: {
"errcode": "M_MISSING_PARAM", "errcode": "M_INVALID_PARAM",
"error": "Create event not among invite state entries." "error": "Create event not among invite state entries."
} }
servers: servers:

51
data/api/server-server/invites-v2.yaml
View file

@ -40,6 +40,28 @@ paths:
Also note that if the remote homeserver is already in the room, it will receive the Also note that if the remote homeserver is already in the room, it will receive the
invite event twice; once through this endpoint, and again through a [federation invite event twice; once through this endpoint, and again through a [federation
transaction](/server-server-api/#transactions). transaction](/server-server-api/#transactions).
Servers MUST apply certain validation to ensure they don't accidentally sign non-invite
events from a malicious server. A specific error code is not mandated, but servers SHOULD
return `M_INVALID_PARAM` if:
* The invite event fails a [signature check](/server-server-api/#validating-hashes-and-signatures-on-received-events).
* The event type is not `m.room.member`.
* The `membership` field inside the event content is not `invite`.
* The event sender is not a user ID on the origin server.
* The `state_key` is not a user ID on the receiving server.
The `invite_room_state` has additional validation, which servers MAY apply to room versions
1 through 11 and SHOULD apply to all other room versions. As with the above errors, servers
SHOULD return `M_INVALID_PARAM` if:
* The `m.room.create` event is missing from `invite_room_state`.
* One or more entries in `invite_room_state` are not formatted according
to the room's version.
* One or more events fails a [signature check](/server-server-api/#validating-hashes-and-signatures-on-received-events).
* One or more events does not reside in the same room as the invite.
Note: Some room versions may require calculating the room ID for an
event rather than relying on the presence of `room_id`.
operationId: sendInviteV2 operationId: sendInviteV2
security: security:
- signedRequest: [] - signedRequest: []
@ -84,8 +106,7 @@ paths:
MUST additionally be formatted according to the room version specification. MUST additionally be formatted according to the room version specification.
Servers might need to apply validation to the `invite_room_state` depending Servers might need to apply validation to the `invite_room_state` depending
on room version. See the `400 M_MISSING_PARAM` error definition for more on room version. See the endpoint description for more information.
information.
Note that events have a different format depending on the room Note that events have a different format depending on the room
version - check the [room version specification](/rooms) for version - check the [room version specification](/rooms) for
@ -154,22 +175,8 @@ paths:
The error should be passed through to clients so that they The error should be passed through to clients so that they
may give better feedback to users. may give better feedback to users.
The `M_MISSING_PARAM` error code is used to indicate one or more of If `M_MISSING_PARAM` or `M_INVALID_PARAM` is returned and the request is associated
the following: with a Client-Server API request, the Client-Server API request SHOULD fail
* The `m.room.create` event is missing from `invite_room_state`.
* One or more entries in `invite_room_state` are not formatted according
to the room's version.
* One or more events fails a [signature check](/server-server-api/#validating-hashes-and-signatures-on-received-events).
* One or more events does not reside in the same room as the invite.
Note: Some room versions may require calculating the room ID for an
event rather than relying on the presence of `room_id`.
Servers MAY apply the validation above to room versions 1 through 11,
and SHOULD apply the validation above to all other room versions.
If `M_MISSING_PARAM` is returned and the request is associated with a
Client-Server API request, the Client-Server API request SHOULD fail
with a 5xx error rather than being passed through. with a 5xx error rather than being passed through.
content: content:
application/json: application/json:
@ -192,11 +199,17 @@ paths:
} }
"403": "403":
description: |- description: |-
The invite is not allowed. This could be for a number of reasons, including: The invite is not allowed.
The `M_FORBIDDEN` error code is used to indicate one of the following:
* The sender is not allowed to send invites to the target user/homeserver. * The sender is not allowed to send invites to the target user/homeserver.
* The homeserver does not permit anyone to invite its users. * The homeserver does not permit anyone to invite its users.
* The homeserver refuses to participate in the room. * The homeserver refuses to participate in the room.
{{% added-in v="1.18"%}} The `M_INVITE_BLOCKED` error code is used to
indicate that the homeserver rejected the invite due to
[invite blocking](/client-server-api/#invite-permission).
content: content:
application/json: application/json:
schema: schema:

49
data/api/server-server/joins-v1.yaml
View file

@ -23,6 +23,17 @@ paths:
description: |- description: |-
Asks the receiving server to return information that the sending Asks the receiving server to return information that the sending
server will need to prepare a join event to get into the room. server will need to prepare a join event to get into the room.
Before signing the returned template and calling `/send_join`,
the sending server MUST verify that:
* the `room_id` is equal to the `roomId` path parameter.
* both the `sender` and `state_key` are equal to the `userId` path parameter.
* the `type` of the event is `m.room.member`.
* the `membership` field inside `content` is `join`.
In case any of the above checks fail, the response MUST be treated as malformed and
discarded. The caller MAY try to join through another server.
operationId: makeJoin operationId: makeJoin
security: security:
- signedRequest: [] - signedRequest: []
@ -36,7 +47,7 @@ paths:
type: string type: string
- in: path - in: path
name: userId name: userId
description: The user ID the join event will be for. description: The user ID the join event will be for. This MUST be a user ID on the origin server.
required: true required: true
example: "@someone:example.org" example: "@someone:example.org"
schema: schema:
@ -238,6 +249,15 @@ paths:
**The request and response body here describe the common **The request and response body here describe the common
event fields in more detail and may be missing other required event fields in more detail and may be missing other required
fields for a PDU.** fields for a PDU.**
The receiving server MUST apply certain validation before accepting the event.
A specific error code is not mandated, but servers SHOULD return `M_INVALID_PARAM` if:
* The join event fails a [signature check](/server-server-api/#validating-hashes-and-signatures-on-received-events).
* The event type is not `m.room.member`.
* The `membership` field inside the event content is not `join`.
* The event sender is not a user ID on the origin server.
* The `state_key` is not equal to the `sender`.
operationId: sendJoinV1 operationId: sendJoinV1
security: security:
- signedRequest: [] - signedRequest: []
@ -388,6 +408,33 @@ paths:
} }
} }
] ]
"400":
description: |-
The request is invalid in some way.
content:
application/json:
schema:
$ref: ../client-server/definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_INVALID_PARAM",
"error": "Not a join event."
}
"403":
description: |-
The room that the joining server is attempting to join does not permit the user
to join.
content:
application/json:
schema:
$ref: ../client-server/definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_FORBIDDEN",
"error": "You are not invited to this room"
}
servers: servers:
- url: "{protocol}://{hostname}{basePath}" - url: "{protocol}://{hostname}{basePath}"
variables: variables:

13
data/api/server-server/joins-v2.yaml
View file

@ -38,6 +38,15 @@ paths:
**The request and response body here describe the common **The request and response body here describe the common
event fields in more detail and may be missing other required event fields in more detail and may be missing other required
fields for a PDU.** fields for a PDU.**
The receiving server MUST apply certain validation before accepting the event.
A specific error code is not mandated, but servers SHOULD return `M_INVALID_PARAM` if:
* The join event fails a [signature check](/server-server-api/#validating-hashes-and-signatures-on-received-events).
* The event type is not `m.room.member`.
* The `membership` field inside the event content is not `join`.
* The event sender is not a user ID on the origin server.
* The `state_key` is not equal to the `sender`.
operationId: sendJoinV2 operationId: sendJoinV2
security: security:
- signedRequest: [] - signedRequest: []
@ -247,6 +256,10 @@ paths:
The error should be passed through to clients so that they The error should be passed through to clients so that they
may give better feedback to users. may give better feedback to users.
If `M_MISSING_PARAM` or `M_INVALID_PARAM` is returned and the request is associated
with a Client-Server API request, the Client-Server API request SHOULD fail
with a 5xx error rather than being passed through.
New in `v1.2`, the following error conditions might happen: New in `v1.2`, the following error conditions might happen:
If the room is [restricted](/client-server-api/#restricted-rooms) If the room is [restricted](/client-server-api/#restricted-rooms)

15
data/api/server-server/keys_query.yaml
View file

@ -34,10 +34,10 @@ paths:
- in: query - in: query
name: minimum_valid_until_ts name: minimum_valid_until_ts
description: |- description: |-
A millisecond POSIX timestamp in milliseconds indicating when the returned A millisecond POSIX timestamp. The returned keys SHOULD be valid
certificates will need to be valid until to be useful to the requesting server. until at least this timestamp.
If not supplied, the current time as determined by the notary server is used. If not supplied, the notary server MUST use the current time.
required: false required: false
example: 1234567890 example: 1234567890
schema: schema:
@ -98,12 +98,11 @@ paths:
type: integer type: integer
format: int64 format: int64
description: |- description: |-
A millisecond POSIX timestamp in milliseconds indicating when A millisecond POSIX timestamp. The returned keys
the returned certificates will need to be valid until to be SHOULD be valid until at least this timestamp.
useful to the requesting server.
If not supplied, the current time as determined by the notary If not supplied, the notary server MUST use the
server is used. current time.
example: 1234567890 example: 1234567890
required: required:
- server_keys - server_keys

35
data/api/server-server/knocks.yaml
View file

@ -23,6 +23,17 @@ paths:
description: |- description: |-
Asks the receiving server to return information that the sending Asks the receiving server to return information that the sending
server will need to prepare a knock event for the room. server will need to prepare a knock event for the room.
Before signing the returned template and calling `/send_knock`,
the sending server MUST verify that:
* the `room_id` is equal to the `roomId` path parameter.
* both the `sender` and `state_key` are equal to the `userId` path parameter.
* the `type` of the event is `m.room.member`.
* the `membership` field inside `content` is `knock`.
In case any of the above checks fail, the response MUST be treated as malformed and
discarded. The caller MAY try to knock through another server.
operationId: makeKnock operationId: makeKnock
security: security:
- signedRequest: [] - signedRequest: []
@ -36,7 +47,7 @@ paths:
type: string type: string
- in: path - in: path
name: userId name: userId
description: The user ID the knock event will be for. description: The user ID the knock event will be for. This MUST be a user ID on the origin server.
required: true required: true
example: "@someone:example.org" example: "@someone:example.org"
schema: schema:
@ -204,6 +215,15 @@ paths:
**The request and response body here describe the common **The request and response body here describe the common
event fields in more detail and may be missing other required event fields in more detail and may be missing other required
fields for a PDU.** fields for a PDU.**
The receiving server MUST apply certain validation before accepting the event.
A specific error code is not mandated, but servers SHOULD return `M_INVALID_PARAM` if:
* The knock event fails a [signature check](/server-server-api/#validating-hashes-and-signatures-on-received-events).
* The event type is not `m.room.member`.
* The `membership` field inside the event content is not `knock`.
* The event sender is not a user ID on the origin server.
* The `state_key` is not equal to the `sender`.
operationId: sendKnock operationId: sendKnock
security: security:
- signedRequest: [] - signedRequest: []
@ -330,6 +350,19 @@ paths:
"$ref": "./examples/invite_or_knock_state.json" "$ref": "./examples/invite_or_knock_state.json"
} }
} }
"400":
description: |-
The request is invalid in some way.
content:
application/json:
schema:
$ref: ../client-server/definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_INVALID_PARAM",
"error": "Not a knock event."
}
"403": "403":
description: |- description: |-
The knocking server or user is not permitted to knock on the room, such as when the The knocking server or user is not permitted to knock on the room, such as when the

35
data/api/server-server/leaving-v1.yaml
View file

@ -23,6 +23,17 @@ paths:
description: |- description: |-
Asks the receiving server to return information that the sending Asks the receiving server to return information that the sending
server will need to prepare a leave event to get out of the room. server will need to prepare a leave event to get out of the room.
Before signing the returned template and calling `/send_leave`,
the sending server MUST verify that:
* the `room_id` is equal to the `roomId` path parameter.
* both the `sender` and `state_key` are equal to the `userId` path parameter.
* the `type` of the event is `m.room.member`.
* the `membership` field inside `content` is `leave`.
In case any of the above checks fail, the response MUST be treated as malformed and
discarded. The caller MAY try to leave through another server.
operationId: makeLeave operationId: makeLeave
security: security:
- signedRequest: [] - signedRequest: []
@ -36,7 +47,7 @@ paths:
type: string type: string
- in: path - in: path
name: userId name: userId
description: The user ID the leave event will be for. description: The user ID the leave event will be for. This MUST be a user ID on the origin server.
required: true required: true
example: "@someone:example.org" example: "@someone:example.org"
schema: schema:
@ -153,6 +164,15 @@ paths:
**The request and response body here describe the common **The request and response body here describe the common
event fields in more detail and may be missing other required event fields in more detail and may be missing other required
fields for a PDU.** fields for a PDU.**
The receiving server MUST apply certain validation before accepting the event.
A specific error code is not mandated, but servers SHOULD return `M_INVALID_PARAM` if:
* The leave event fails a [signature check](/server-server-api/#validating-hashes-and-signatures-on-received-events).
* The event type is not `m.room.member`.
* The `membership` field inside the event content is not `leave`.
* The event sender is not a user ID on the origin server.
* The `state_key` is not equal to the `sender`.
operationId: sendLeaveV1 operationId: sendLeaveV1
security: security:
- signedRequest: [] - signedRequest: []
@ -249,6 +269,19 @@ paths:
200, 200,
{} {}
] ]
"400":
description: |-
The request is invalid in some way.
content:
application/json:
schema:
$ref: ../client-server/definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_INVALID_PARAM",
"error": "Not a leave event."
}
servers: servers:
- url: "{protocol}://{hostname}{basePath}" - url: "{protocol}://{hostname}{basePath}"
variables: variables:

22
data/api/server-server/leaving-v2.yaml
View file

@ -38,6 +38,15 @@ paths:
**The request and response body here describe the common **The request and response body here describe the common
event fields in more detail and may be missing other required event fields in more detail and may be missing other required
fields for a PDU.** fields for a PDU.**
The receiving server MUST apply certain validation before accepting the event.
A specific error code is not mandated, but servers SHOULD return `M_INVALID_PARAM` if:
* The leave event fails a [signature check](/server-server-api/#validating-hashes-and-signatures-on-received-events).
* The event type is not `m.room.member`.
* The `membership` field inside the event content is not `leave`.
* The event sender is not a user ID on the origin server.
* The `state_key` is not equal to the `sender`.
operationId: sendLeaveV2 operationId: sendLeaveV2
security: security:
- signedRequest: [] - signedRequest: []
@ -134,6 +143,19 @@ paths:
examples: examples:
response: response:
value: {} value: {}
"400":
description: |-
The request is invalid in some way.
content:
application/json:
schema:
$ref: ../client-server/definitions/errors/error.yaml
examples:
response:
value: {
"errcode": "M_INVALID_PARAM",
"error": "Not a leave event."
}
servers: servers:
- url: "{protocol}://{hostname}{basePath}" - url: "{protocol}://{hostname}{basePath}"
variables: variables:

2
data/api/server-server/user_devices.yaml
View file

@ -79,7 +79,7 @@ paths:
- keys - keys
master_key: master_key:
type: object type: object
description: The user\'s master cross-signing key. description: The user\'s master signing key.
allOf: allOf:
- $ref: ../client-server/definitions/cross_signing_key.yaml - $ref: ../client-server/definitions/cross_signing_key.yaml
- example: - example:

4
data/api/server-server/user_keys.yaml
View file

@ -194,8 +194,8 @@ paths:
x-addedInMatrixVersion: "1.1" x-addedInMatrixVersion: "1.1"
type: object type: object
description: |- description: |-
Information on the master cross-signing keys of the queried users. Information on the master signing keys of the queried users.
A map from user ID, to master key information. For each key, the A map from user ID, to master signing key information. For each key, the
information returned will be the same as uploaded via information returned will be the same as uploaded via
`/keys/device_signing/upload`, along with the signatures `/keys/device_signing/upload`, along with the signatures
uploaded via `/keys/signatures/upload` that the user is uploaded via `/keys/signatures/upload` that the user is

7
data/event-schemas/examples/m.invite_permission_config.yaml Normal file
View file

@ -0,0 +1,7 @@
{
"$ref": "core/event.json",
"type": "m.invite_permission_config",
"content": {
"default_action": "block"
}
}

21
data/event-schemas/schema/m.invite_permission_config.yaml Normal file
View file

@ -0,0 +1,21 @@
---
$schema: https://json-schema.org/draft/2020-12/schema
allOf:
- $ref: core-event-schema/event.yaml
- title: Invite Permission
type: object
description: |-
The permission configuration for receiving invites for the current account.
properties:
content:
type: object
properties:
default_action:
type: string
description: |-
When set to `block`, the user does not wish to receive *any* room invites, and they
should be rejected automatically by the homeserver.
A missing, invalid or unsupported value means that the user wants to receive invites
as normal. Other parts of the specification might still have effects on invites, like
[ignoring users](/client-server-api/#ignoring-users).