Merge f42ce28bfe into 6e16a19ac9

- do not use the term 'cross-signing keys' anymore: Previously, the term
  'cross-signing keys' was used to refer to the master, user-signing and
  self-signing keys. This is not ideal since the master key is used for
  cross-signing but may also be used to sign the backup key, for example.
  In these contexts, the master key is not used for cross-signing.
  The term 'cross-signing keys' has therefor been replaced by 'keys used
  for cross-signing' or, more explicitely, by 'master, user-signing and
  self-signing key'.
- the naming of the master key has been harmonised (no more 'master
  cross-signing key' or 'master signing keys'). Also the abbr. 'MSK' has been
  replaced by 'MK'.
- in the QR code example, the term 'cross-signing key' has been replaced
  by 'master key' since in mode 0x00, the current user's own master key and
  what the device thinks the other user's master key is used.
- it has been made more explicit that private keys used for cross-signing can
  be stored on the server are stored as described in the secrets module (as
  opposed to store them in unencrypted form)

Signed-off-by: codedust <codedust@so.urceco.de>

.github/workflows/main.yml

@@ -1,7 +1,7 @@
 name: "Spec"
 
 env:
-  HUGO_VERSION: 0.139.0
+  HUGO_VERSION: 0.148.1
   PYTHON_VERSION: 3.13
 
 on:

README.md

@@ -61,7 +61,7 @@ place after an MSC has been accepted, not as part of a proposal itself.
 
 1. Install the extended version (often the OS default) of Hugo:
    <https://gohugo.io/getting-started/installing>. Note that at least Hugo
-   v0.123.1 is required.
+   v0.146.0 is required.
 
    Alternatively, use the Docker image at
    https://hub.docker.com/r/klakegg/hugo/. (The "extended edition" is required

changelogs/application_service/newsfragments/2132.clarification

@@ -0,0 +1 @@
+Declare the Application Service Registration schema to follow JSON Schema spec 2020-12.

changelogs/client_server/newsfragments/2132.clarification

@@ -0,0 +1 @@
+Declare the event schemas to follow JSON Schema spec 2020-12.

changelogs/client_server/newsfragments/2188.clarification

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

changelogs/internal/newsfragments/2160.clarification

@@ -0,0 +1 @@
+Upgrade the docsy theme to version 0.12.0.

config/_default/hugo.toml

@@ -8,7 +8,7 @@ enableRobotsTXT = true
 # We disable RSS, because (a) it's useless, (b) Hugo seems to generate broken
 # links to it when used with a --baseURL (for example, https://spec.matrix.org/v1.4/
 # contains `<link rel="alternate" type="application/rss&#43;xml" href="/v1.4/v1.4/index.xml">`).
-disableKinds = ["taxonomy", "RSS"]
+disableKinds = ["taxonomy", "rss"]
 
 [languages]
 [languages.en]
@@ -134,7 +134,7 @@ sidebar_menu_compact = true
 [module]
   [module.hugoVersion]
     extended = true
-    min = "0.123.1"
+    min = "0.146.0"
   [[module.imports]]
     path = "github.com/matrix-org/docsy"
     disable = false

content/changelog/_index.md

@@ -1,6 +1,7 @@
 ---
 title: Changelog
 type: docs
+layout: changelog-index
 weight: 1000
 ---
 

content/client-server-api/modules/end_to_end_encryption.md

@@ -93,7 +93,7 @@ Example:
 ```
 
 `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 keys used for [cross-signing](#cross-signing).
 
 `signed_curve25519` keys are used for [one-time and fallback keys](#one-time-and-fallback-keys).
 
@@ -675,7 +675,7 @@ The process between Alice and Bob verifying each other would be:
 15. Assuming they match, Alice and Bob's devices each calculate Message
     Authentication Codes (MACs) for:
     * Each of the keys that they wish the other user to verify (usually their
-      device ed25519 key and their master cross-signing key).
+      device ed25519 key and their master key, see below).
     * The complete list of key IDs that they wish the other user to verify.
 
     The MAC calculation is defined [below](#mac-calculation).
@@ -931,16 +931,16 @@ and can be translated online:
 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
 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 ed25519 key pairs that
 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.
 
-Each user has three ed25519 key pairs for cross-signing:
+Each user has three ed25519 key pairs used for cross-signing:
 
--   a master key (MSK) that serves as the user's identity in
-    cross-signing and signs their other cross-signing keys;
+-   a master key (MK) 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
-    to --that signs other users' master keys; and
+    to -- that signs other users' master keys; and
 -   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
@@ -950,13 +950,15 @@ 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
 with her user-signing key.
 
-Users upload their cross-signing keys to the server using [POST
+Users upload the public part of their master, user-signing and self-signing
+key to the server using [POST
 /\_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
 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)
-to retrieve Alice's device and cross-signing keys.
+to retrieve Alice's device keys, as well as their master, user-signing and
+self-signing key.
 
 If Alice has a device and wishes to send an encrypted message to Bob,
 she can trust Bob's device if:
@@ -971,13 +973,13 @@ The following diagram illustrates how keys are signed:
 
 ```
     +------------------+                ..................   +----------------+
-    | +--------------+ |   ..................            :   | +------------+ |
-    | |              v v   v            :   :            v   v v            | |
-    | |           +-----------+         :   :         +-----------+         | |
-    | |           | Alice MSK |         :   :         |  Bob MSK  |         | |
-    | |           +-----------+         :   :         +-----------+         | |
-    | |             |       :           :   :           :       |           | |
-    | |          +--+       :...        :   :        ...:       +--+        | |
+    | +--------------+ |  ...................            :   | +------------+ |
+    | |              v v  v             :   :            v   v v            | |
+    | |           +----------+          :   :         +----------+          | |
+    | |           | Alice MK |          :   :         |  Bob MK  |          | |
+    | |           +----------+          :   :         +----------+          | |
+    | |             |      :            :   :           :      |            | |
+    | |          +--+      :....        :   :        ...:      +---+        | |
     | |          v             v        :   :        v             v        | |
     | |    +-----------+ .............  :   :  ............. +-----------+  | |
     | |    | Alice SSK | : Alice USK :  :   :  :  Bob USK  : |  Bob SSK  |  | |
@@ -1004,11 +1006,11 @@ signatures that she cannot see:
     +------------------+                +----------------+   +----------------+
     | +--------------+ |                |                |   | +------------+ |
     | |              v v                |                v   v v            | |
-    | |           +-----------+         |             +-----------+         | |
-    | |           | Alice MSK |         |             |  Bob MSK  |         | |
-    | |           +-----------+         |             +-----------+         | |
-    | |             |       |           |                       |           | |
-    | |          +--+       +--+        |                       +--+        | |
+    | |           +----------+          |             +----------+          | |
+    | |           | Alice MK |          |             |  Bob MK  |          | |
+    | |           +----------+          |             +----------+          | |
+    | |             |      |            |                      |            | |
+    | |          +--+      +---+        |                      +---+        | |
     | |          v             v        |                          v        | |
     | |    +-----------+ +-----------+  |                    +-----------+  | |
     | |    | Alice SSK | | Alice USK |  |                    |  Bob SSK  |  | |
@@ -1024,16 +1026,16 @@ signatures that she cannot see:
 ```
 
 [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 key by treating the master public key, encoded using unpadded
 base64, as the device ID, and treating it as a normal device. For
 example, if Alice and Bob verify each other using SAS, Alice's
 `m.key.verification.mac` message to Bob may include
 `"ed25519:alices+master+public+key": "alices+master+public+key"` in the
 `mac` property. Servers therefore must ensure that device IDs will not
-collide with cross-signing public keys.
+collide with public keys used for cross-signing.
 
-The cross-signing private keys can be stored on the server or shared with other
-devices using the [Secrets](#secrets) module.  When doing so, the master,
+Using the [Secrets](#secrets) module the private keys used for cross-signing can
+be stored on the server or shared with other devices.  When doing so, the master,
 user-signing, and self-signing keys are identified using the names
 `m.cross_signing.master`, `m.cross_signing.user_signing`, and
 `m.cross_signing.self_signing`, respectively, and the keys are base64-encoded
@@ -1052,14 +1054,14 @@ If a user's client sees that any other user has changed their master
 key, that client must notify the user about the change before allowing
 communication between the users to continue.
 
-Since device key IDs (`ed25519:DEVICE_ID`) and cross-signing key IDs
-(`ed25519:PUBLIC_KEY`) occupy the same namespace, clients must ensure that they
-use the correct keys when verifying.
+Since device key IDs (`ed25519:DEVICE_ID`) as well as master, user-signing and
+self-signing key IDs (`ed25519:PUBLIC_KEY`) occupy the same namespace, clients
+must ensure that they use the correct keys when verifying.
 
-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
-rely on the server being well-behaved and should take the following precautions
-against this.
+While servers MUST not allow devices to have the same IDs as keys used for
+cross-signing, a malicious server could construct such a situation, so clients
+must not rely on the server being well-behaved and should take the following
+precautions against this:
 
 1. Clients MUST refer to keys by their public keys during the verification
    process, rather than only by the key ID.
@@ -1067,7 +1069,8 @@ against this.
    verification process, and ensure that they do not change in the course of
    verification.
 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 key used for
+   cross-signing.
 
 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
@@ -1104,7 +1107,7 @@ user-signing keys.
 
 Verifying by QR codes provides a quick way to verify when one of the parties
 has a device capable of scanning a QR code. The QR code encodes both parties'
-master signing keys as well as a random shared secret that is used to allow
+master keys as well as a random shared secret that is used to allow
 bi-directional verification from a single scan.
 
 To advertise the ability to show a QR code, clients use the names
@@ -1202,15 +1205,14 @@ The binary segment MUST be of the following form:
     bytes of the ID 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:
-  - 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 public 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:
   - 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
     public key is
-  - if `0x02`, then what the device thinks the user's master cross-signing public
-    key is
+  - if `0x02`, then what the device thinks the user's master public key is
 - 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
   secret, and it is not a fixed size, clients will just use the remainder of
@@ -1221,14 +1223,14 @@ For example, if Alice displays a QR code encoding the following binary data:
 ```
       "MATRIX"    |ver|mode| len   | event ID
  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
-  00 01 02 03 04 05 06 07 ...   10 11 12 13 14 15 16 17 ...      20 21 22 23 24 25 26 27
+| 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
 ```
 
-this indicates that Alice is verifying another user (say Bob), in response to
-the request from event "$ABCD...", her cross-signing key is
+Mode `0x00` indicates that Alice is verifying another user (say Bob), in
+response to the request from event "$ABCD...", her master key is
 `0001020304050607...` (which is "AAECAwQFBg..." in base64), she thinks that
-Bob's cross-signing key is `1011121314151617...` (which is "EBESExQVFh..." in
+Bob's master key is `1011121314151617...` (which is "EBESExQVFh..." in
 base64), and the shared secret is `2021222324252627` (which is "ICEiIyQlJic" in
 base64).
 
@@ -1300,8 +1302,8 @@ one of its variants.
 Clients must only store keys in backups after they have ensured that the
 `auth_data` is trusted. This can be done either by:
 
-- checking that it is signed by the user's [master cross-signing
-  key](#cross-signing) or by a verified device belonging to the same user, or
+- checking that it is signed by the user's [master key](#cross-signing)
+  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
   source. Trusted sources for the private key include the user entering the
   key, retrieving the key stored in [secret storage](#secret-storage), or
@@ -1786,13 +1788,14 @@ a way to identify the server's support for fallback keys.
 
 | Parameter  | Type      | Description                                                                                                                                                      |
 |------------|-----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| changed    | [string]  | List of users who have updated their device identity or cross-signing keys, or who now share an encrypted room with the client since the previous sync response. |
+| changed    | [string]  | List of users who have updated their device identity or their master, self-signing or user-signing keys, or who now share an encrypted room with the client since the previous sync response. |
 | left       | [string]  | List of users with whom we do not share any encrypted rooms anymore since the previous sync response.                                                            |
 
 {{% boxes/note %}}
 For optimal performance, Alice should be added to `changed` in Bob's
-sync only when she updates her devices or cross-signing keys, or when
-Alice and Bob now share a room but didn't share any room previously.
+sync only when she updates her devices or master, self-signing or
+user-signing keys, or when Alice and Bob now share a room but didn't
+share any room previously.
 However, for the sake of simpler logic, a server may add Alice to
 `changed` when Alice and Bob share a new room, even if they previously
 already shared a room.

data/api/application-service/definitions/namespace_list.yaml

@@ -11,6 +11,7 @@
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
+$schema: https://json-schema.org/draft/2020-12/schema
 
 type: array
 items:

data/api/application-service/definitions/registration.yaml

@@ -11,6 +11,7 @@
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
+$schema: https://json-schema.org/draft/2020-12/schema
 
 type: object
 title: Registration

data/api/client-server/cross_signing.yaml

@@ -21,16 +21,16 @@ paths:
       x-addedInMatrixVersion: "1.1"
       x-changedInMatrixVersion:
         "1.11": UIA is not always required for this endpoint.
-      summary: Upload cross-signing keys.
+      summary: Upload keys used for cross-signing.
       description: |-
-        Publishes cross-signing keys for the user.
+        Publishes keys used for cross-signing for the user.
 
         This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api).
 
         User-Interactive Authentication MUST be performed, except in these cases:
-        - there is no existing cross-signing master key uploaded to the homeserver, OR
-        - there is an existing cross-signing master key and it exactly matches the
-          cross-signing master key provided in the request body. If there are any additional
+        - there is no existing master key uploaded to the homeserver, OR
+        - there is an existing master key and it exactly matches the
+          master 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
           match the existing keys stored on the server. In other words, the request contains
           no new keys.

data/api/client-server/definitions/cross_signing_key.yaml

@@ -13,7 +13,7 @@
 # limitations under the License.
 type: object
 title: CrossSigningKey
-description: Cross signing key
+description: Key used for cross signing
 properties:
   user_id:
     type: string

data/api/client-server/keys.yaml

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

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

@@ -17,7 +17,7 @@ type: object
 title: m.signing_key_update
 description: |-
   An EDU that lets servers push details to each other when one of their users
-  updates their cross-signing keys.
+  updates their keys used for cross-signing.
 allOf:
   - $ref: ../edu.yaml
   - type: object
@@ -34,7 +34,7 @@ allOf:
         properties:
           user_id:
             type: string
-            description: The user ID whose cross-signing keys have changed.
+            description: The user ID whose keys have changed.
             example: "@alice:example.com"
           master_key:
             allOf:

data/api/server-server/user_devices.yaml

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

data/api/server-server/user_keys.yaml

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

data/event-schemas/moderation_policy_rule.yaml

@@ -11,6 +11,8 @@
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
+$schema: https://json-schema.org/draft/2020-12/schema
+
 properties:
   entity:
     description: |-

data/event-schemas/schema/components/sdp_stream_metadata.yaml

@@ -1,3 +1,5 @@
+$schema: https://json-schema.org/draft/2020-12/schema
+
 type: object
 x-addedInMatrixVersion: "1.10"
 description: |-

data/event-schemas/schema/core-event-schema/call_event.yaml

@@ -1,3 +1,5 @@
+$schema: https://json-schema.org/draft/2020-12/schema
+
 description: "The content of all call events shares a set of common fields: those
   of room events and some additional VoIP specific fields."
 properties:

data/event-schemas/schema/core-event-schema/event.yaml

@@ -1,3 +1,5 @@
+$schema: https://json-schema.org/draft/2020-12/schema
+
 description: The basic set of fields all events must have.
 properties:
   content:

data/event-schemas/schema/core-event-schema/msgtype_infos/avatar_info.yaml

@@ -1,3 +1,5 @@
+$schema: https://json-schema.org/draft/2020-12/schema
+
 description: Metadata about an avatar image.
 properties:
   h:

data/event-schemas/schema/core-event-schema/msgtype_infos/image_info.yaml

@@ -1,3 +1,5 @@
+$schema: https://json-schema.org/draft/2020-12/schema
+
 description: Metadata about an image.
 properties:
   h:

data/event-schemas/schema/core-event-schema/msgtype_infos/thumbnail_info.yaml

@@ -1,3 +1,5 @@
+$schema: https://json-schema.org/draft/2020-12/schema
+
 description: Metadata about a thumbnail image.
 properties:
   h:

data/event-schemas/schema/core-event-schema/room_event.yaml

@@ -1,3 +1,5 @@
+$schema: https://json-schema.org/draft/2020-12/schema
+
 title: RoomEvent
 description: Room Events have the following fields.
 allOf:

data/event-schemas/schema/core-event-schema/state_event.yaml

@@ -1,3 +1,5 @@
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
 - $ref: room_event.yaml
 - $ref: sync_state_event.yaml

data/event-schemas/schema/core-event-schema/stripped_state.yaml

@@ -18,6 +18,8 @@
 # difficult because the schema would be at two different locations, with
 # different relative pathing.
 
+$schema: https://json-schema.org/draft/2020-12/schema
+
 title: StrippedStateEvent
 type: object
 description: |-

data/event-schemas/schema/core-event-schema/sync_room_event.yaml

@@ -17,6 +17,8 @@
 # be on events, so we give it a whole event structure as a base for room_event.
 # This base doesn't declare a room_id, which instead appears in the room_event.
 
+$schema: https://json-schema.org/draft/2020-12/schema
+
 title: SyncRoomEvent
 description: In addition to the Event fields, Room Events have the following additional
   fields.

data/event-schemas/schema/core-event-schema/sync_state_event.yaml

@@ -14,6 +14,8 @@
 
 # See sync_room_event.yaml for why this file is here.
 
+$schema: https://json-schema.org/draft/2020-12/schema
+
 title: SyncStateEvent
 description: In addition to the Room Event fields, State Events have the following
   additional fields.

data/event-schemas/schema/core-event-schema/unsigned_prop.yaml

@@ -11,6 +11,7 @@
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
+$schema: https://json-schema.org/draft/2020-12/schema
 
 title: UnsignedData
 type: object

data/event-schemas/schema/m.accepted_terms.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 description: |-

data/event-schemas/schema/m.call.answer.yaml

@@ -1,4 +1,5 @@
 {
+    "$schema": "https://json-schema.org/draft/2020-12/schema",
     "type": "object",
     "description": "This event is sent by the callee when they wish to answer the call.",
     "x-weight": 40,

data/event-schemas/schema/m.call.candidates.yaml

@@ -1,3 +1,5 @@
+$schema: https://json-schema.org/draft/2020-12/schema
+
 type: object
 description: |-
   This event is sent by callers after sending an invite and by the callee after

data/event-schemas/schema/m.call.hangup.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 type: object
 description: |
   Sent by either party to signal their termination of the call. This can

data/event-schemas/schema/m.call.invite.yaml

@@ -1,4 +1,5 @@
 {
+    "$schema": "https://json-schema.org/draft/2020-12/schema",
     "type": "object",
     "description": "This event is sent by the caller when they wish to establish a call.",
     "x-weight": 10,

data/event-schemas/schema/m.call.negotiate.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 type: object
 description: |
   Provides SDP negotiation semantics for media pause, hold/resume, ICE restarts

data/event-schemas/schema/m.call.reject.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 type: object
 description: |
   If the `m.call.invite` event has `version` `"1"`, a client wishing to

data/event-schemas/schema/m.call.sdp_stream_metadata_changed.yaml

@@ -1,3 +1,5 @@
+$schema: https://json-schema.org/draft/2020-12/schema
+
 type: object
 x-addedInMatrixVersion: "1.11"
 x-weight: 70

data/event-schemas/schema/m.call.select_answer.yaml

@@ -1,4 +1,5 @@
 {
+    "$schema": "https://json-schema.org/draft/2020-12/schema",
     "type": "object",
     "description": "This event is sent by the caller's client once it has decided which other client to talk to, by selecting one of multiple possible incoming `m.call.answer` events. Its `selected_party_id` field indicates the answer it's chosen. The `call_id` and `party_id` of the caller is also included. If the callee's client sees a `select_answer` for an answer with party ID other than the one it sent, it ends the call and informs the user the call was answered elsewhere. It does not send any events. Media can start flowing before this event is seen or even sent.  Clients that implement previous versions of this specification will ignore this event and behave as they did before.",
     "x-addedInMatrixVersion": "1.7",

data/event-schemas/schema/m.direct.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 description: |-

data/event-schemas/schema/m.dummy.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.forwarded_room_key.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.fully_read.yaml

@@ -1,4 +1,5 @@
 {
+    "$schema": "https://json-schema.org/draft/2020-12/schema",
     "type": "object",
     "title": "Read Marker Location Event",
     "description": "The current location of the user's read marker in a room. This event appears in the user's room account data for the room the marker is applicable for.",

data/event-schemas/schema/m.identity_server.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 description: |-

data/event-schemas/schema/m.ignored_user_list.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 description: |-

data/event-schemas/schema/m.key.verification.accept.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.key.verification.cancel.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.key.verification.done.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.key.verification.key.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.key.verification.m.relates_to.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 description: |-
   Required when sent as an in-room message. Indicates the
   `m.key.verification.request` that this message is related to. Note that for

data/event-schemas/schema/m.key.verification.mac.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.key.verification.ready.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.key.verification.request.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.key.verification.start$m.reciprocate.v1.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.key.verification.start$m.sas.v1.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.key.verification.start.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.marked_unread.yaml

@@ -1,4 +1,5 @@
 {
+    "$schema": "https://json-schema.org/draft/2020-12/schema",
     "type": "object",
     "title": "Unread Marker Event",
     "description": "The current state of the user's unread marker in a room. This event appears in the user's room account data for the room the marker is applicable for.",

data/event-schemas/schema/m.policy.rule.room.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: A moderation policy rule which affects room IDs and room aliases.

data/event-schemas/schema/m.policy.rule.server.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: A moderation policy rule which affects servers.

data/event-schemas/schema/m.policy.rule.user.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: A moderation policy rule which affects users.

data/event-schemas/schema/m.presence.yaml

@@ -1,4 +1,5 @@
 {
+    "$schema": "https://json-schema.org/draft/2020-12/schema",
     "type": "object",
     "title": "Presence Event",
     "description": "Informs the client of a user's presence state change.",

data/event-schemas/schema/m.push_rules.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 description: Describes all push rules for this user.

data/event-schemas/schema/m.reaction.yaml

@@ -1,3 +1,5 @@
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/room_event.yaml
 description: |-

data/event-schemas/schema/m.receipt.yaml

@@ -1,3 +1,5 @@
+$schema: https://json-schema.org/draft/2020-12/schema
+
 type: object
 title: Receipt Event
 description: Informs the client of new receipts.

data/event-schemas/schema/m.room.avatar.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: A picture that is associated with the room. This can be displayed alongside the room information.

data/event-schemas/schema/m.room.canonical_alias.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: |-

data/event-schemas/schema/m.room.create.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: This is the first event in a room and cannot be changed. It acts as the root of all other events.

data/event-schemas/schema/m.room.encrypted.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.room.encryption.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: Defines how messages sent in this room should be encrypted.

data/event-schemas/schema/m.room.guest_access.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: 'This event controls whether guest users are allowed to join rooms. If this event is absent, servers should act as if it is present and has the guest_access value "forbidden".'

data/event-schemas/schema/m.room.history_visibility.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: This event controls whether a user can see the events that happened in a room from before they joined.

data/event-schemas/schema/m.room.join_rules.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: |

data/event-schemas/schema/m.room.member.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: |-

data/event-schemas/schema/m.room.message$m.audio.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/room_event.yaml
 description: This message represents a single audio clip.

data/event-schemas/schema/m.room.message$m.emote.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/room_event.yaml
 description: "This message is similar to `m.text` except that the sender is 'performing' the action contained in the `body` key, similar to `/me` in IRC. This message should be prefixed by the name of the sender. This message could also be represented in a different colour to distinguish it from regular `m.text` messages."

data/event-schemas/schema/m.room.message$m.file.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/room_event.yaml
 description: This message represents a generic file.

data/event-schemas/schema/m.room.message$m.image.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/room_event.yaml
 description: This message represents a single image and an optional thumbnail.

data/event-schemas/schema/m.room.message$m.key.verification.request.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/room_event.yaml
 description:

data/event-schemas/schema/m.room.message$m.location.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/room_event.yaml
 description: This message represents a real-world location.

data/event-schemas/schema/m.room.message$m.notice.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/room_event.yaml
 description: 'The `m.notice` type is primarily intended for responses from automated clients. An `m.notice` message must be treated the same way as a regular `m.text` message with two exceptions. Firstly, clients should present `m.notice` messages to users in a distinct manner, and secondly, `m.notice` messages must never be automatically responded to. This helps to prevent infinite-loop situations where two automated clients continuously exchange messages.'

data/event-schemas/schema/m.room.message$m.server_notice.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/room_event.yaml
 description: Represents a server notice for a user.

data/event-schemas/schema/m.room.message$m.text.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/room_event.yaml
 description: This message is the most basic message and is used to represent text.

data/event-schemas/schema/m.room.message$m.video.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/room_event.yaml
 description: This message represents a single video clip.

data/event-schemas/schema/m.room.message.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/room_event.yaml
 description: 'This event is used when sending messages in a room. Messages are not limited to be text. The `msgtype` key outlines the type of message, e.g. text, audio, image, video, etc. The `body` key is text and MUST be used with every kind of `msgtype` as a fallback mechanism for when a client cannot render a message. This allows clients to display *something* even if it is just plain text.'

data/event-schemas/schema/m.room.name.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: |-

data/event-schemas/schema/m.room.pinned_events.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: This event is used to "pin" particular events in a room for other participants to review later. The order of the pinned events is guaranteed and based upon the order supplied in the event. Clients should be aware that the current user may not be able to see some of the events pinned due to visibility settings in the room. Clients are responsible for determining if a particular event in the pinned list is displayable, and have the option to not display it if it cannot be pinned in the client.

data/event-schemas/schema/m.room.power_levels.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: |-

data/event-schemas/schema/m.room.redaction.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/room_event.yaml
 description: 'This event is created by the server to describe which event has been redacted, by whom, and optionally why. The event that has been redacted is specified in the `redacts` event level key. Redacting an event means that all keys not required by the protocol are stripped off, allowing messages to be hidden or allowing admins to remove offensive or illegal content.'

data/event-schemas/schema/m.room.server_acl.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 title: Server ACL
 description: |-
   An event to indicate which servers are permitted to participate in the

data/event-schemas/schema/m.room.third_party_invite.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: |-

data/event-schemas/schema/m.room.tombstone.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: 'A state event signifying that a room has been upgraded to a different room version, and that clients should go there.'

data/event-schemas/schema/m.room.topic.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: |-

data/event-schemas/schema/m.room_key.withheld.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.room_key.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.room_key_request.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 

data/event-schemas/schema/m.secret.request.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 description: |-

data/event-schemas/schema/m.secret.send.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/event.yaml
 description: |-

data/event-schemas/schema/m.space.child.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: Defines the relationship of a child room to a space-room. Has no effect in rooms which are not [spaces](/client-server-api/#spaces).

data/event-schemas/schema/m.space.parent.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/state_event.yaml
 description: Defines the relationship of a room to a parent space-room.

data/event-schemas/schema/m.sticker.yaml

@@ -1,4 +1,6 @@
 ---
+$schema: https://json-schema.org/draft/2020-12/schema
+
 allOf:
   - $ref: core-event-schema/room_event.yaml
 description: This message represents a single sticker image.