diff --git a/content/client-server-api/_index.md b/content/client-server-api/_index.md index 2a4ba3b9e..27cbc389b 100644 --- a/content/client-server-api/_index.md +++ b/content/client-server-api/_index.md @@ -1111,7 +1111,7 @@ which has no `m.identity_server` account data event should not end up with the client's default identity server in their account data, unless the user first visits their account settings to set the identity server. -{{m\_identity\_server\_event}} +{{% event event="m.identity_server" %}} ## Capabilities negotiation @@ -1385,14 +1385,12 @@ available room versions. Room events are split into two categories: -State Events -These are events which update the metadata state of the room (e.g. room +* **State events**: These are events which update the metadata state of the room (e.g. room topic, room membership etc). State is keyed by a tuple of event `type` and a `state_key`. State in the room with the same key-tuple will be overwritten. -Message events -These are events which describe transient "once-off" activity in a room: +* **Message events**: These are events which describe transient "once-off" activity in a room: typically communication such as sending an instant message or setting up a VoIP call. @@ -1416,11 +1414,15 @@ assuming the client has access to the `com.example` namespace. Note that the structure of these events may be different than those in the server-server API. -{{common\_event\_fields}} +#### Event fields -{{common\_room\_event\_fields}} +{{% event-fields event_type="event" %}} -#### State Event Fields +#### Room event fields + +{{% event-fields event_type="room_event" %}} + +#### State event fields In addition to the fields of a Room Event, State Events have the following fields. @@ -1460,15 +1462,15 @@ This section is a work in progress. This specification outlines several standard event types, all of which are prefixed with `m.` -{{m\_room\_canonical\_alias\_event}} +{{% event event="m.room.canonical_alias" %}} -{{m\_room\_create\_event}} +{{% event event="m.room.create" %}} -{{m\_room\_join\_rules\_event}} +{{% event event="m.room.join_rules" %}} -{{m\_room\_member\_event}} +{{% event event="m.room.member" %}} -{{m\_room\_power\_levels\_event}} +{{% event event="m.room.power_levels" %}} #### Historical events @@ -1682,7 +1684,7 @@ the topic to be removed from the room. #### Events -{{m\_room\_redaction\_event}} +{{% event event="m.room.redaction" %}} #### Client behaviour diff --git a/content/client-server-api/modules/dm.md b/content/client-server-api/modules/dm.md index c9f4511ae..c4f06bf3b 100644 --- a/content/client-server-api/modules/dm.md +++ b/content/client-server-api/modules/dm.md @@ -19,7 +19,7 @@ whether a chat is 'direct' to an invitee. #### Events -{{m\_direct\_event}} +{{% event event="m.direct" %}} #### Client behaviour diff --git a/content/client-server-api/modules/end_to_end_encryption.md b/content/client-server-api/modules/end_to_end_encryption.md index b3efaeb22..aea43eaaa 100644 --- a/content/client-server-api/modules/end_to_end_encryption.md +++ b/content/client-server-api/modules/end_to_end_encryption.md @@ -466,11 +466,11 @@ process. After the handshake, the verification process begins. -{{m\_key\_verification\_request\_event}} +{{% event event="m.key.verification.request" %}} -{{m\_key\_verification\_start\_event}} +{{% event event="m.key.verification.start" %}} -{{m\_key\_verification\_cancel\_event}} +{{% event event="m.key.verification.cancel" %}} ##### Short Authentication String (SAS) verification @@ -634,13 +634,13 @@ following error codes are used in addition to those already specified: - `m.mismatched_commitment`: The hash commitment did not match. - `m.mismatched_sas`: The SAS did not match. -{{m\_key\_verification\_start\_m\_sas\_v1\_event}} +{{% event event="m.key.verification.start$m.sas.v1" %}} -{{m\_key\_verification\_accept\_event}} +{{% event event="m.key.verification.accept" %}} -{{m\_key\_verification\_key\_event}} +{{% event event="m.key.verification.key" %}} -{{m\_key\_verification\_mac\_event}} +{{% event event="m.key.verification.mac" %}} ###### HKDF calculation @@ -1355,17 +1355,17 @@ messages. ##### Events -{{m\_room\_encryption\_event}} +{{% event event="m.room.encryption" %}} -{{m\_room\_encrypted\_event}} +{{% event event="m.room.encrypted" %}} -{{m\_room\_key\_event}} +{{% event event="m.room_key" %}} -{{m\_room\_key\_request\_event}} +{{% event event="m.room_key_request" %}} -{{m\_forwarded\_room\_key\_event}} +{{% event event="m.room_key" %}} -{{m\_dummy\_event}} +{{% event event="m.dummy" %}} ##### Key management API @@ -1451,4 +1451,4 @@ by including a `withheld` property in the `m.forwarded_room_key` message that is an object with the `code` and `reason` properties from the `m.room_key.withheld` message. -{{m\_room\_key\_withheld\_event}} +{{% event event="m.room_key.withheld" %}} diff --git a/content/client-server-api/modules/guest_access.md b/content/client-server-api/modules/guest_access.md index b68a8e018..7d04035e9 100644 --- a/content/client-server-api/modules/guest_access.md +++ b/content/client-server-api/modules/guest_access.md @@ -32,7 +32,7 @@ rather than allowing all homeservers to enforce the rules on each other. #### Events -{{m\_room\_guest\_access\_event}} +{{% event event="m.room.guest_access" %}} #### Client behaviour diff --git a/content/client-server-api/modules/history_visibility.md b/content/client-server-api/modules/history_visibility.md index 8eba36431..0a00f01ee 100644 --- a/content/client-server-api/modules/history_visibility.md +++ b/content/client-server-api/modules/history_visibility.md @@ -43,7 +43,7 @@ setting at that time was more restrictive. #### Events -{{m\_room\_history\_visibility\_event}} +{{% event event="m.room.history_visibility" %}} #### Client behaviour diff --git a/content/client-server-api/modules/ignore_users.md b/content/client-server-api/modules/ignore_users.md index 18fadb675..51bb480db 100644 --- a/content/client-server-api/modules/ignore_users.md +++ b/content/client-server-api/modules/ignore_users.md @@ -11,7 +11,7 @@ and servers can implement the ignoring of users. #### Events -{{m\_ignored\_user\_list\_event}} +{{% event event="m.ignored_user_list" %}} #### Client behaviour diff --git a/content/client-server-api/modules/instant_messaging.md b/content/client-server-api/modules/instant_messaging.md index 8550a7aed..6f60d5a0d 100644 --- a/content/client-server-api/modules/instant_messaging.md +++ b/content/client-server-api/modules/instant_messaging.md @@ -11,9 +11,9 @@ room itself such as a room name and topic. #### Events -{{m\_room\_message\_event}} +{{% event event="m.room.message" %}} -{{m\_room\_message\_feedback\_event}} +{{% event event="m.room.message.feedback" %}} Usage of this event is discouraged for several reasons: - The number of feedback events will grow very quickly with the number @@ -24,13 +24,13 @@ Usage of this event is discouraged for several reasons: - There are no guarantees that the client has seen the event ID being acknowledged. -{{m\_room\_name\_event}} +{{% event event="m.room.name" %}} -{{m\_room\_topic\_event}} +{{% event event="m.room.topic" %}} -{{m\_room\_avatar\_event}} +{{% event event="m.room.avatar" %}} -{{m\_room\_pinned\_events\_event}} +{{% event event="m.room.pinned_events" %}} ##### m.room.message msgtypes @@ -116,7 +116,7 @@ extensible message formatting options, such as the proposal [MSC1767](https://github.com/matrix-org/matrix-doc/pull/1767). {{% /boxes/note %}} -{{msgtype\_events}} +{{% msgtypes %}} #### Client behaviour diff --git a/content/client-server-api/modules/moderation_policies.md b/content/client-server-api/modules/moderation_policies.md index 923df71e7..c164b1b1e 100644 --- a/content/client-server-api/modules/moderation_policies.md +++ b/content/client-server-api/modules/moderation_policies.md @@ -97,11 +97,11 @@ rules against rooms can describe a room ID or room alias - the subscriber is responsible for resolving the alias to a room ID if desired. -{{m\_policy\_rule\_user\_event}} +{{% event event="m.policy.rule.user" %}} -{{m\_policy\_rule\_room\_event}} +{{% event event="m.policy.rule.room" %}} -{{m\_policy\_rule\_server\_event}} +{{% event event="m.policy.rule.server" %}} #### Client behaviour diff --git a/content/client-server-api/modules/presence.md b/content/client-server-api/modules/presence.md index 683d4839c..9944f086c 100644 --- a/content/client-server-api/modules/presence.md +++ b/content/client-server-api/modules/presence.md @@ -30,7 +30,7 @@ enum of one of the following: #### Events -{{presence\_events}} +{{% event-group group_name="m.presence" %}} #### Client behaviour diff --git a/content/client-server-api/modules/push.md b/content/client-server-api/modules/push.md index 16e9ad716..90546050a 100644 --- a/content/client-server-api/modules/push.md +++ b/content/client-server-api/modules/push.md @@ -666,7 +666,7 @@ When a user changes their push rules a `m.push_rules` event is sent to all clients in the `account_data` section of their next `/sync` request. The content of the event is the current push rules for the user. -{{m\_push\_rules\_event}} +{{% event event="m.push_rules" %}} ###### Examples diff --git a/content/client-server-api/modules/read_markers.md b/content/client-server-api/modules/read_markers.md index d2738821d..a2c0150b7 100644 --- a/content/client-server-api/modules/read_markers.md +++ b/content/client-server-api/modules/read_markers.md @@ -24,7 +24,7 @@ The fully read marker is kept under an `m.fully_read` event. If the event does not exist on the user's account data, the fully read marker should be considered to be the user's read receipt location. -{{m\_fully\_read\_event}} +{{% event event="m.fully_read" %}} #### Client behaviour diff --git a/content/client-server-api/modules/receipts.md b/content/client-server-api/modules/receipts.md index 05ea5ca1d..fb28aacd7 100644 --- a/content/client-server-api/modules/receipts.md +++ b/content/client-server-api/modules/receipts.md @@ -24,7 +24,7 @@ information on how read receipts affect notification counts. Each `user_id`, `receipt_type` pair must be associated with only a single `event_id`. -{{m\_receipt\_event}} +{{% event event="m.receipt" %}} #### Client behaviour diff --git a/content/client-server-api/modules/room_upgrades.md b/content/client-server-api/modules/room_upgrades.md index 08738d0ab..dbcb82334 100644 --- a/content/client-server-api/modules/room_upgrades.md +++ b/content/client-server-api/modules/room_upgrades.md @@ -11,7 +11,7 @@ to upgrade to a different room version when needed. #### Events -{{m\_room\_tombstone\_event}} +{{% event event="m.room.tombstone" %}} #### Client behaviour diff --git a/content/client-server-api/modules/server_acls.md b/content/client-server-api/modules/server_acls.md index 5ee09501e..fc3089155 100644 --- a/content/client-server-api/modules/server_acls.md +++ b/content/client-server-api/modules/server_acls.md @@ -16,7 +16,7 @@ set of servers, or retroactively make the room no longer federate with any other server, similar to setting the `m.federate` value on the [m.room.create](#mroomcreate) event. -{{m\_room\_server\_acl\_event}} +{{% event event="m.room.server_acl" %}} {{% boxes/note %}} Port numbers are not supported because it is unclear to parsers whether diff --git a/content/client-server-api/modules/server_notices.md b/content/client-server-api/modules/server_notices.md index 13bafc46f..199acd85b 100644 --- a/content/client-server-api/modules/server_notices.md +++ b/content/client-server-api/modules/server_notices.md @@ -36,7 +36,7 @@ maximum. New connections are being refused by the server. What defines "active" is left as an implementation detail, however servers are encouraged to treat syncing users as "active". -{{m\_room\_message\_m\_server\_notice\_event}} +{{% event event="m.room.message$m.server_notice" %}} #### Client behaviour diff --git a/content/client-server-api/modules/stickers.md b/content/client-server-api/modules/stickers.md index b705d9ac3..234ebba25 100644 --- a/content/client-server-api/modules/stickers.md +++ b/content/client-server-api/modules/stickers.md @@ -22,7 +22,7 @@ when the sticker image is clicked. Sticker events are received as a single `m.sticker` event in the `timeline` section of a room, in a `/sync`. -{{m\_sticker\_event}} +{{% event event="m.sticker" %}} #### Client behaviour diff --git a/content/client-server-api/modules/tags.md b/content/client-server-api/modules/tags.md index 28a74c9bc..c47be0c1d 100644 --- a/content/client-server-api/modules/tags.md +++ b/content/client-server-api/modules/tags.md @@ -59,7 +59,7 @@ tags are defined in the `m.*` namespace: - `m.server_notice`: Used to identify [Server Notice Rooms](#server-notices). -{{m\_tag\_event}} +{{% event event="m.tag" %}} #### Client Behaviour diff --git a/content/client-server-api/modules/third_party_invites.md b/content/client-server-api/modules/third_party_invites.md index 45c94a93f..4a5c63e50 100644 --- a/content/client-server-api/modules/third_party_invites.md +++ b/content/client-server-api/modules/third_party_invites.md @@ -31,7 +31,7 @@ invitee does indeed own that third party identifier. See the #### Events -{{m\_room\_third\_party\_invite\_event}} +{{% event event="m.room.third_party_invite" %}} #### Client behaviour diff --git a/content/client-server-api/modules/typing_notifications.md b/content/client-server-api/modules/typing_notifications.md index 12417a642..b9254cdb9 100644 --- a/content/client-server-api/modules/typing_notifications.md +++ b/content/client-server-api/modules/typing_notifications.md @@ -12,7 +12,7 @@ events scoped to a `room_id`. This means they do not form part of the #### Events -{{m\_typing\_event}} +{{% event event="m.typing" %}} #### Client behaviour diff --git a/content/client-server-api/modules/voip_events.md b/content/client-server-api/modules/voip_events.md index b8b94df2a..db33eb4c0 100644 --- a/content/client-server-api/modules/voip_events.md +++ b/content/client-server-api/modules/voip_events.md @@ -15,7 +15,7 @@ send call events to rooms with exactly two participants. #### Events -{{voip\_events}} +{{% event-group group_name="m.call" %}} #### Client behaviour diff --git a/content/identity-service-api.md b/content/identity-service-api.md index 3ce8b6fe8..60115306c 100644 --- a/content/identity-service-api.md +++ b/content/identity-service-api.md @@ -196,7 +196,7 @@ the client should not expect that the server will not respond with another `M_TERMS_NOT_SIGNED` on their next request. The terms the user has just accepted are appended to `m.accepted_terms`. -{{m\_accepted\_terms\_event}} +{{% event event="m.accepted_terms" %}} {{% http-api spec="identity" api="v2_terms" %}} diff --git a/content/rooms/v1.md b/content/rooms/v1.md index 450eea6de..b76147df1 100644 --- a/content/rooms/v1.md +++ b/content/rooms/v1.md @@ -276,7 +276,7 @@ Some consequences of these rules: Events in version 1 rooms have the following structure: -{{definition\_ss\_pdu}} +{{% definition path="api/server-server/definitions/pdu" %}} ### Canonical JSON diff --git a/content/rooms/v3.md b/content/rooms/v3.md index 71d64c1a0..e1966b6e0 100644 --- a/content/rooms/v3.md +++ b/content/rooms/v3.md @@ -60,7 +60,7 @@ Additionally, the `auth_events` and `prev_events` have had a format change compared to other room versions to make it easier to handle. Instead of a tuple of values, they are now plain lists of events. -{{definition\_ss\_pdu\_v3}} +{{% definition path="api/server-server/definitions/pdu_v3" %}} ### Changes to APIs diff --git a/content/rooms/v4.md b/content/rooms/v4.md index d2aa8a236..c2853a2c3 100644 --- a/content/rooms/v4.md +++ b/content/rooms/v4.md @@ -58,4 +58,4 @@ receiving end of an event, the server should compute the relevant event ID for itself. Room version 3 also changes the format of `auth_events` and `prev_events` in a PDU. -{{definition\_ss\_pdu\_v4}} +{{% definition path="api/server-server/definitions/pdu_v4" %}} diff --git a/content/server-server-api.md b/content/server-server-api.md index beb175dd8..7e38e4b19 100644 --- a/content/server-server-api.md +++ b/content/server-server-api.md @@ -567,7 +567,7 @@ EDUs, by comparison to PDUs, do not have an ID, a room ID, or a list of "previous" IDs. They are intended to be non-persistent data such as user presence, typing notifications, etc. -{{definition\_ss\_edu}} +{{% definition path="api/server-server/definitions/edu" %}} ## Room State Resolution @@ -850,7 +850,7 @@ need to be sent to other servers in the room so their users are aware of the same state. Receiving servers should verify that the user is in the room, and is a user belonging to the sending server. -{{definition\_ss\_event\_schemas\_m\_typing}} +{{% definition path="api/server-server/definitions/event-schemas/m.typing" %}} ## Presence @@ -861,7 +861,7 @@ Servers should only send presence updates for users that the receiving server would be interested in. Such as the receiving server sharing a room with a given user. -{{definition\_ss\_event\_schemas\_m\_presence}} +{{% definition path="api/server-server/definitions/event-schemas/m.presence" %}} ## Receipts @@ -872,7 +872,7 @@ where in the event graph the user has read up to. Read receipts for events that a user sent do not need to be sent. It is implied that by sending the event the user has read up to the event. -{{definition\_ss\_event\_schemas\_m\_receipt}} +{{% definition path="api/server-server/definitions/event-schemas/m.receipt" %}} ## Querying for information @@ -945,7 +945,7 @@ recognise, it must resynchronise its list by calling the {{% http-api spec="server-server" api="user_devices" %}} -{{definition\_ss\_event\_schemas\_m\_device\_list\_update}} +{{% definition path="api/server-server/definitions/event-schemas/m.device_list_update" %}} ## End-to-End Encryption @@ -960,7 +960,7 @@ proxied through to the client. {{% http-api spec="server-server" api="user_keys" %}} -{{definition\_ss\_event\_schemas\_m\_signing\_key\_update}} +{{% definition path="api/server-server/definitions/event-schemas/m.signing_key_update" %}} ## Send-to-device messaging @@ -971,7 +971,7 @@ involved. Each send-to-device message should be sent to the destination server using the following EDU: -{{definition\_ss\_event\_schemas\_m\_direct\_to\_device}} +{{% definition path="api/server-server/definitions/event-schemas/m.direct_to_device" %}} ## Content Repository