diff --git a/changelogs/internal/newsfragments/1975.clarification b/changelogs/internal/newsfragments/1975.clarification new file mode 100644 index 00000000..4edcc477 --- /dev/null +++ b/changelogs/internal/newsfragments/1975.clarification @@ -0,0 +1 @@ +Fix formatting of `added-in` and `changed-in` shortcodes by using `%` delimiter. diff --git a/content/appendices.md b/content/appendices.md index f9dbb455..92616111 100644 --- a/content/appendices.md +++ b/content/appendices.md @@ -761,7 +761,7 @@ wish to consider handling them as `u`, `r`, and `e` respectively. {{% /boxes/note %}} {{% boxes/note %}} -{{< changed-in v="1.11" >}} +{{% changed-in v="1.11" %}} Referencing event IDs within a room identified by room alias (`r`) rather than room ID (`roomid`) is now deprecated. We are not aware of these ever having been used in practice, and are nonsensical given room aliases are mutable. @@ -858,7 +858,7 @@ Examples of matrix.to URIs are: * Link to `@alice:example.org`: `https://matrix.to/#/%40alice%3Aexample.org` {{% boxes/note %}} -{{< changed-in v="1.11" >}} +{{% changed-in v="1.11" %}} Referencing event IDs within a room identified by room alias rather than room ID is now deprecated. We are not aware of these ever having been used in practice, and are nonsensical given room aliases are mutable. diff --git a/content/client-server-api/_index.md b/content/client-server-api/_index.md index 0fd5f6b0..389ff927 100644 --- a/content/client-server-api/_index.md +++ b/content/client-server-api/_index.md @@ -242,7 +242,8 @@ The `retry_after_ms` property MAY be included to tell the client how long they have to wait in milliseconds before they can try again. This property is deprecated, in favour of the `Retry-After` header. -{{< changed-in v="1.10" >}}: `retry_after_ms` property deprecated in favour of `Retry-After` header. +{{% changed-in v="1.10" %}}: `retry_after_ms` property deprecated in favour of `Retry-After` header. + ### Transaction identifiers The client-server API typically uses `HTTP PUT` to submit requests with @@ -436,7 +437,7 @@ could mean one of four things: 1. the access token was never valid. 2. the access token has been logged out. 3. the access token has been [soft logged out](#soft-logout). -4. {{< added-in v="1.3" >}} the access token [needs to be refreshed](#refreshing-access-tokens). +4. {{% added-in v="1.3" %}} the access token [needs to be refreshed](#refreshing-access-tokens). When a client receives an error code of `M_UNKNOWN_TOKEN`, it should: @@ -1350,7 +1351,7 @@ client supports it, the client should redirect the user to the is complete, the client will need to submit a `/login` request matching `m.login.token`. -{{< added-in v="1.7" >}} Already-authenticated clients can additionally generate +{{% added-in v="1.7" %}} Already-authenticated clients can additionally generate a token for their user ID if supported by the homeserver using [`POST /login/get_token`](/client-server-api/#post_matrixclientv1loginget_token). @@ -2342,7 +2343,7 @@ The endpoints where the server *should* include bundled aggregations are: * [`GET /sync`](#get_matrixclientv3sync) when the relevant section has a `limited` value of `true`. * [`POST /search`](#post_matrixclientv3search) for any matching events under `room_events`. -* {{< added-in v="1.4" >}} [`GET /rooms/{roomId}/threads`](#get_matrixclientv1roomsroomidthreads) +* {{% added-in v="1.4" %}} [`GET /rooms/{roomId}/threads`](#get_matrixclientv1roomsroomidthreads) {{% boxes/note %}} The server is **not** required to return bundled aggregations on deprecated endpoints diff --git a/content/client-server-api/modules/content_repo.md b/content/client-server-api/modules/content_repo.md index 1be6b071..a3e38b43 100644 --- a/content/client-server-api/modules/content_repo.md +++ b/content/client-server-api/modules/content_repo.md @@ -16,12 +16,12 @@ When serving content, the server SHOULD provide a `Content-Security-Policy` header. The recommended policy is `sandbox; default-src 'none'; script-src 'none'; plugin-types application/pdf; style-src 'unsafe-inline'; object-src 'self';`. -{{< added-in v="1.4" >}} The server SHOULD additionally provide +{{% added-in v="1.4" %}} The server SHOULD additionally provide `Cross-Origin-Resource-Policy: cross-origin` when serving content to allow (web) clients to access restricted APIs such as `SharedArrayBuffer` when interacting with the media repository. -{{< changed-in v="1.11" >}} The unauthenticated download endpoints have been +{{% changed-in v="1.11" %}} The unauthenticated download endpoints have been deprecated in favour of newer, authenticated, ones. This change includes updating the paths of all media endpoints from `/_matrix/media/*` to `/_matrix/client/{version}/media/*`, with the exception of the `/upload` and `/create` endpoints. The upload/create @@ -44,7 +44,7 @@ mxc:/// Clients can access the content repository using the following endpoints. -{{< changed-in v="1.11" >}} A number of endpoints under the /_matrix/media hierarchy +{{% changed-in v="1.11" %}} A number of endpoints under the /_matrix/media hierarchy have been deprecated and replaced with new endpoints which require authentication. The deprecated endpoints are marked in the section below. diff --git a/content/client-server-api/modules/event_replacements.md b/content/client-server-api/modules/event_replacements.md index 9afe304e..50109d07 100644 --- a/content/client-server-api/modules/event_replacements.md +++ b/content/client-server-api/modules/event_replacements.md @@ -188,7 +188,7 @@ replacement event. ##### Server-side aggregation of `m.replace` relationships -{{< changed-in v="1.7" >}} +{{% changed-in v="1.7" %}} Note that there can be multiple events with an `m.replace` relationship to a given event (for example, if an event is edited multiple times). These should diff --git a/content/client-server-api/modules/guest_access.md b/content/client-server-api/modules/guest_access.md index 86ac031a..ada9e71e 100644 --- a/content/client-server-api/modules/guest_access.md +++ b/content/client-server-api/modules/guest_access.md @@ -40,13 +40,13 @@ for retrieving events and associated media: * [GET /rooms/{roomId}/event/{eventId}](#get_matrixclientv3roomsroomideventeventid) * [GET /rooms/{roomId}/state/{eventType}/{stateKey}](#get_matrixclientv3roomsroomidstateeventtypestatekey) * [GET /rooms/{roomId}/messages](#get_matrixclientv3roomsroomidmessages) -* {{< added-in v="1.1" >}} [GET /rooms/{roomId}/members](#get_matrixclientv3roomsroomidmembers) +* {{% added-in v="1.1" %}} [GET /rooms/{roomId}/members](#get_matrixclientv3roomsroomidmembers) * [GET /rooms/{roomId}/initialSync](#get_matrixclientv3roomsroomidinitialsync) * [GET /sync](#get_matrixclientv3sync) * [GET /events](#get_matrixclientv3events) as used for room previews. -* {{< added-in v="1.12" >}} [GET /media/download/{serverName}/{mediaId}](#get_matrixclientv1mediadownloadservernamemediaid) -* {{< added-in v="1.12" >}} [GET /media/download/{serverName}/{mediaId}/{fileName}](#get_matrixclientv1mediadownloadservernamemediaidfilename) -* {{< added-in v="1.12" >}} [GET /media/thumbnail/{serverName}/{mediaId}](#get_matrixclientv1mediathumbnailservernamemediaid) +* {{% added-in v="1.12" %}} [GET /media/download/{serverName}/{mediaId}](#get_matrixclientv1mediadownloadservernamemediaid) +* {{% added-in v="1.12" %}} [GET /media/download/{serverName}/{mediaId}/{fileName}](#get_matrixclientv1mediadownloadservernamemediaidfilename) +* {{% added-in v="1.12" %}} [GET /media/thumbnail/{serverName}/{mediaId}](#get_matrixclientv1mediathumbnailservernamemediaid) The following API endpoints are allowed to be accessed by guest accounts for sending events: @@ -55,9 +55,9 @@ for sending events: * [POST /rooms/{roomId}/leave](#post_matrixclientv3roomsroomidleave) * [PUT /rooms/{roomId}/send/{eventType}/{txnId}](#put_matrixclientv3roomsroomidsendeventtypetxnid) - * {{< changed-in v="1.2" >}} Guests can now send *any* event type rather than just `m.room.message` events. + * {{% changed-in v="1.2" %}} Guests can now send *any* event type rather than just `m.room.message` events. -* {{< added-in v="1.2" >}} [PUT /rooms/{roomId}/state/{eventType}/{stateKey}](#put_matrixclientv3roomsroomidstateeventtypestatekey) +* {{% added-in v="1.2" %}} [PUT /rooms/{roomId}/state/{eventType}/{stateKey}](#put_matrixclientv3roomsroomidstateeventtypestatekey) * [PUT /sendToDevice/{eventType}/{txnId}](#put_matrixclientv3sendtodeviceeventtypetxnid) The following API endpoints are allowed to be accessed by guest accounts @@ -67,7 +67,7 @@ for their own account maintenance: * [GET /devices](#get_matrixclientv3devices) * [GET /devices/{deviceId}](#get_matrixclientv3devicesdeviceid) * [PUT /devices/{deviceId}](#put_matrixclientv3devicesdeviceid) -* {{< added-in v="1.2" >}} [GET /account/whoami](#get_matrixclientv3accountwhoami) +* {{% added-in v="1.2" %}} [GET /account/whoami](#get_matrixclientv3accountwhoami) The following API endpoints are allowed to be accessed by guest accounts for end-to-end encryption: diff --git a/content/client-server-api/modules/push.md b/content/client-server-api/modules/push.md index 0b8e132e..3b256f01 100644 --- a/content/client-server-api/modules/push.md +++ b/content/client-server-api/modules/push.md @@ -525,7 +525,7 @@ Definition: **`.m.rule.is_user_mention`** -{{< added-in v="1.7" >}} +{{% added-in v="1.7" %}} Matches any message which contains the user's Matrix ID in the list of `user_ids` under the `m.mentions` property. @@ -594,7 +594,7 @@ Definition: **`.m.rule.is_room_mention`** -{{< added-in v="1.7" >}} +{{% added-in v="1.7" %}} Matches any message from a sender with the proper power level with the `room` property of the `m.mentions` property set to `true`. @@ -1072,7 +1072,7 @@ ahead), however if the `m.read.private` receipt were to be updated to event D then the user has read up to D (the `m.read` receipt is now behind the `m.read.private` receipt). -{{< added-in v="1.4" >}} When handling threaded read receipts, the server is to +{{% added-in v="1.4" %}} When handling threaded read receipts, the server is to partition the notification count to each thread (with the main timeline being its own thread). To determine if an event is part of a thread the server follows the [event relationship](#forming-relationships-between-events) until it finds a diff --git a/content/client-server-api/modules/read_markers.md b/content/client-server-api/modules/read_markers.md index 830a441f..960f50b7 100644 --- a/content/client-server-api/modules/read_markers.md +++ b/content/client-server-api/modules/read_markers.md @@ -29,7 +29,7 @@ The client cannot update fully read markers by directly modifying the `m.fully_read` account data event. Instead, the client must make use of the read markers API to change the values. -{{< changed-in v="1.4" >}} `m.read.private` receipts can now be sent from +{{% changed-in v="1.4" %}} `m.read.private` receipts can now be sent from `/read_markers`. The read markers API can additionally update the user's read receipt diff --git a/content/client-server-api/modules/receipts.md b/content/client-server-api/modules/receipts.md index d8733e19..f4d87f25 100644 --- a/content/client-server-api/modules/receipts.md +++ b/content/client-server-api/modules/receipts.md @@ -1,7 +1,7 @@ ### Receipts -{{< changed-in v="1.4" >}} Added private read receipts. +{{% changed-in v="1.4" %}} Added private read receipts. This module adds in support for receipts. These receipts are a form of acknowledgement of an event. This module defines the `m.read` receipt @@ -19,7 +19,7 @@ that the user had read all events *up to* the referenced event. See the [Receiving notifications](#receiving-notifications) section for more information on how read receipts affect notification counts. -{{< added-in v="1.4" >}} Read receipts exist in three major forms: +{{% added-in v="1.4" %}} Read receipts exist in three major forms: * Unthreaded: Denotes a read-up-to receipt regardless of threads. This is how pre-threading read receipts worked. * Threaded, main timeline: Denotes a read-up-to receipt for events not in a @@ -31,7 +31,7 @@ Threaded read receipts are discussed in further detail [below](#threaded-read-re #### Events -{{< changed-in v="1.4" >}} Each `user_id`, `receipt_type`, and categorisation +{{% changed-in v="1.4" %}} Each `user_id`, `receipt_type`, and categorisation (unthreaded, or `thread_id`) tuple must be associated with only a single `event_id`. @@ -39,7 +39,7 @@ Threaded read receipts are discussed in further detail [below](#threaded-read-re #### Client behaviour -{{< changed-in v="1.4" >}} Altered to support threaded read receipts. +{{% changed-in v="1.4" %}} Altered to support threaded read receipts. In `/sync`, receipts are listed under the `ephemeral` array of events for a given room. New receipts that come down the event streams are diff --git a/content/client-server-api/modules/report_content.md b/content/client-server-api/modules/report_content.md index 92288eee..651b0939 100644 --- a/content/client-server-api/modules/report_content.md +++ b/content/client-server-api/modules/report_content.md @@ -21,11 +21,11 @@ rooms instead of individual events. Server administrators and safety teams should, therefore, be cautious not to shut down rooms that might otherwise be legitimate. -{{< changed-in v="1.8" >}} When processing event reports, servers MUST +{{% changed-in v="1.8" %}} When processing event reports, servers MUST verify that the reporting user is currently joined to the room the event is in before accepting a report. -{{< added-in v="1.12" >}} Contrarily, servers MUST NOT restrict room reports +{{% added-in v="1.12" %}} Contrarily, servers MUST NOT restrict room reports based on whether or not the reporting user is joined to the room. This is because users can be exposed to harmful content without being joined to a room. For instance, through room directories or invites. diff --git a/content/client-server-api/modules/room_upgrades.md b/content/client-server-api/modules/room_upgrades.md index aacedf12..647fb377 100644 --- a/content/client-server-api/modules/room_upgrades.md +++ b/content/client-server-api/modules/room_upgrades.md @@ -30,7 +30,7 @@ server: 1. Checks that the user has permission to send `m.room.tombstone` events in the room. -2. {{< changed-in v="1.4" >}} Creates a replacement room with a `m.room.create` event containing a +2. {{% changed-in v="1.4" %}} Creates a replacement room with a `m.room.create` event containing a `predecessor` field, the applicable `room_version`, and a `type` field which is copied from the `predecessor` room. If no `type` is set on the previous room, no `type` is specified on the new room's create event diff --git a/content/rooms/fragments/v3-auth-rules.md b/content/rooms/fragments/v3-auth-rules.md index 9fb56327..aec33743 100644 --- a/content/rooms/fragments/v3-auth-rules.md +++ b/content/rooms/fragments/v3-auth-rules.md @@ -1,6 +1,6 @@ --- --- -{{< added-in v=3 >}} In room versions 1 and 2, events need a +{{% added-in v=3 %}} In room versions 1 and 2, events need a signature from the domain of the `event_id` in order to be considered valid. This room version does not include an `event_id` over federation in the same respect, so does not need a signature from that server. diff --git a/content/rooms/fragments/v8-auth-rules.md b/content/rooms/fragments/v8-auth-rules.md index 8fe2654d..8da010ef 100644 --- a/content/rooms/fragments/v8-auth-rules.md +++ b/content/rooms/fragments/v8-auth-rules.md @@ -54,7 +54,7 @@ The rules are as follows: 4. If type is `m.room.member`: 1. If there is no `state_key` property, or no `membership` property in `content`, reject. - 2. {{< added-in v=8 >}} + 2. {{% added-in v=8 %}} If `content` has a `join_authorised_via_users_server` property: 1. If the event is not validly signed by the homeserver of the user ID denoted by the key, reject. @@ -65,7 +65,7 @@ The rules are as follows: 3. If the `sender` is banned, reject. 4. If the `join_rule` is `invite` or `knock` then allow if membership state is `invite` or `join`. - 5. {{< added-in v=8 >}} + 5. {{% added-in v=8 %}} If the `join_rule` is `restricted`: 1. If membership state is `join` or `invite`, allow. 2. If the `join_authorised_via_users_server` key in `content` diff --git a/content/rooms/v10.md b/content/rooms/v10.md index ad56ce05..974a0822 100644 --- a/content/rooms/v10.md +++ b/content/rooms/v10.md @@ -141,7 +141,7 @@ The rules are as follows: 3. If the `sender` is banned, reject. 4. If the `join_rule` is `invite` or `knock` then allow if membership state is `invite` or `join`. - 5. {{< changed-in v=10 >}} + 5. {{% changed-in v=10 %}} If the `join_rule` is `restricted` or `knock_restricted`: 1. If membership state is `join` or `invite`, allow. 2. If the `join_authorised_via_users_server` key in `content` @@ -197,7 +197,7 @@ The rules are as follows: than the `sender`'s power level, allow. 3. Otherwise, reject. 7. If `membership` is `knock`: - 1. {{< changed-in v=10 >}} + 1. {{% changed-in v=10 %}} If the `join_rule` is anything other than `knock` or `knock_restricted`, reject. 2. If `sender` does not match `state_key`, reject. @@ -214,11 +214,11 @@ The rules are as follows: 8. If the event has a `state_key` that starts with an `@` and does not match the `sender`, reject. 9. If type is `m.room.power_levels`: - 1. {{< added-in v=10 >}} + 1. {{% added-in v=10 %}} If any of the properties `users_default`, `events_default`, `state_default`, `ban`, `redact`, `kick`, or `invite` in `content` are present and not an integer, reject. - 2. {{< added-in v=10 >}} + 2. {{% added-in v=10 %}} If either of the properties `events` or `notifications` in `content` are present and not an object with values that are integers, reject. diff --git a/content/rooms/v11.md b/content/rooms/v11.md index 887b17ef..08edfc01 100644 --- a/content/rooms/v11.md +++ b/content/rooms/v11.md @@ -12,7 +12,7 @@ rules. ### Redactions -{{< added-in v=11 >}} The top-level `origin`, `membership`, and `prev_state` properties +{{% added-in v=11 %}} The top-level `origin`, `membership`, and `prev_state` properties are no longer protected from redaction. The [`m.room.create`](/client-server-api#mroomcreate) event now keeps the entire `content` property. The [`m.room.redaction`](/client-server-api#mroomredaction) event keeps the `redacts` property under `content`. The @@ -112,7 +112,7 @@ the [Handling redactions](#handling-redactions) section. The rules are as follows: -1. {{< changed-in v=11 >}} +1. {{% changed-in v=11 %}} If type is `m.room.create`: 1. If it has any `prev_events`, reject. 2. If the domain of the `room_id` does not match the domain of the @@ -142,7 +142,7 @@ The rules are as follows: 1. If the event is not validly signed by the homeserver of the user ID denoted by the key, reject. 3. If `membership` is `join`: - 1. {{< changed-in v=11 >}} + 1. {{% changed-in v=11 %}} If the only previous event is an `m.room.create` and the `state_key` is the sender, allow. 2. If the `sender` does not match `state_key`, reject. diff --git a/content/rooms/v3.md b/content/rooms/v3.md index bee12698..6a3522b7 100644 --- a/content/rooms/v3.md +++ b/content/rooms/v3.md @@ -90,7 +90,7 @@ The complete structure of a event in a v3 room is shown below. ### Authorization rules {{% boxes/note %}} -{{< added-in v=3 >}} `m.room.redaction` events are subject to auth rules in +{{% added-in v=3 %}} `m.room.redaction` events are subject to auth rules in the same way as any other event. In practice, that means they will normally be allowed by the auth rules, unless the `m.room.power_levels` event sets a power level requirement for `m.room.redaction`events via the `events` or `events_default` properties. In diff --git a/content/rooms/v6.md b/content/rooms/v6.md index a3f4a682..b2a5f024 100644 --- a/content/rooms/v6.md +++ b/content/rooms/v6.md @@ -16,7 +16,7 @@ which implement the redaction algorithm locally should refer to the ### Redactions -{{< added-in v=6 >}} All significant meaning for `m.room.aliases` +{{% added-in v=6 %}} All significant meaning for `m.room.aliases` has been removed from the redaction algorithm. The remaining rules are the same as past room versions. @@ -41,11 +41,11 @@ in [room version 5](/rooms/v5). ### Authorization rules -{{< added-in v=6 >}} Rule 4, which related specifically to events +{{% added-in v=6 %}} Rule 4, which related specifically to events of type `m.room.aliases`, is removed. `m.room.aliases` events must still pass authorization checks relating to state events. -{{< added-in v=6 >}} Additionally, the authorization rules for events of +{{% added-in v=6 %}} Additionally, the authorization rules for events of type `m.room.power_levels` now include a `notifications` property under `content`. This updates rules 10.4 and 10.5 (now 9.4 and 9.5), which checked the `events` property. @@ -175,12 +175,12 @@ The rules are as follows: power level, reject. 2. If the new value is higher than the `sender`'s current power level, reject. - 4. {{< changed-in v=6 >}} + 4. {{% changed-in v=6 %}} For each entry being changed in, or removed from, the `events` or `notifications` properties: 1. If the current value is greater than the `sender`'s current power level, reject. - 5. {{< changed-in v=6 >}} + 5. {{% changed-in v=6 %}} For each entry being added to, or changed in, the `events` or `notifications` properties: 1. If the new value is greater than the `sender`'s current power diff --git a/content/rooms/v7.md b/content/rooms/v7.md index 2af07c16..216646d3 100644 --- a/content/rooms/v7.md +++ b/content/rooms/v7.md @@ -33,7 +33,7 @@ as do the versions v6 is based upon. ### Authorization rules -{{< added-in v=7 >}} For checks performed upon `m.room.member` events, a +{{% added-in v=7 %}} For checks performed upon `m.room.member` events, a new point for `membership=knock` is added. Events must be signed by the server denoted by the `sender` property. @@ -90,7 +90,7 @@ The rules are as follows: `state_key` is the creator, allow. 2. If the `sender` does not match `state_key`, reject. 3. If the `sender` is banned, reject. - 4. {{< changed-in v=7 >}} + 4. {{% changed-in v=7 %}} If the `join_rule` is `invite` or `knock` then allow if membership state is `invite` or `join`. 5. If the `join_rule` is `public`, allow. @@ -122,7 +122,7 @@ The rules are as follows: the *invite level*, allow. 5. Otherwise, reject. 4. If `membership` is `leave`: - 1. {{< changed-in v=7 >}} + 1. {{% changed-in v=7 %}} If the `sender` matches `state_key`, allow if and only if that user's current membership state is `invite`, `join`, or `knock`. @@ -142,7 +142,7 @@ The rules are as follows: the *ban level*, and the *target user*'s power level is less than the `sender`'s power level, allow. 3. Otherwise, reject. - 6. {{< added-in v=7 >}} + 6. {{% added-in v=7 %}} If `membership` is `knock`: 1. If the `join_rule` is anything other than `knock`, reject. 2. If `sender` does not match `state_key`, reject. diff --git a/content/rooms/v8.md b/content/rooms/v8.md index 173073c5..c6c116a8 100644 --- a/content/rooms/v8.md +++ b/content/rooms/v8.md @@ -84,7 +84,7 @@ room without invite. Otherwise, the room version inherits all properties of ### Authorization rules -{{< added-in v=8 >}} For checks performed upon `m.room.member` events, new +{{% added-in v=8 %}} For checks performed upon `m.room.member` events, new points for handling `content.join_authorised_via_users_server` are added (Rule 4.2 and 4.3.5). diff --git a/content/rooms/v9.md b/content/rooms/v9.md index 5573b957..582ff6b4 100644 --- a/content/rooms/v9.md +++ b/content/rooms/v9.md @@ -18,7 +18,7 @@ Clients which implement the redaction algorithm locally should refer to the ### Redactions -{{< added-in v=9 >}} [`m.room.member`](/client-server-api#mroommember) events +{{% added-in v=9 %}} [`m.room.member`](/client-server-api#mroommember) events now keep `join_authorised_via_users_server` in addition to other keys in `content` when being redacted. diff --git a/content/server-server-api.md b/content/server-server-api.md index 4e829bed..e1b57c96 100644 --- a/content/server-server-api.md +++ b/content/server-server-api.md @@ -148,7 +148,7 @@ to send. The process overall is as follows: Requests must be made with a `Host` header of `:`. The target server must present a valid certificate for ``. - 3. {{< added-in v="1.8" >}} If `` is not an IP literal and no + 3. {{% added-in v="1.8" %}} If `` is not an IP literal and no `` is present, an SRV record is looked up for `_matrix-fed._tcp.`. This may result in another hostname (to be resolved using AAAA or A records) and port. @@ -171,7 +171,7 @@ to send. The process overall is as follows: ``. The target server must present a valid certificate for ``. -4. {{< added-in v="1.8" >}} If the `/.well-known` request resulted in an error response, a server is +4. {{% added-in v="1.8" %}} If the `/.well-known` request resulted in an error response, a server is found by resolving an SRV record for `_matrix-fed._tcp.`. This may result in a hostname (to be resolved using AAAA or A records) and port. Requests are made to the resolved IP address and port, with a `Host` @@ -375,7 +375,7 @@ The authorization parameters to include are: - `origin`: the server name of the sending server. This is the same as the `origin` field from JSON described in step 1. -- `destination`: {{< added-in v="1.3" >}} the server name of the receiving +- `destination`: {{% added-in v="1.3" %}} the server name of the receiving server. This is the same as the `destination` field from the JSON described in step 1. For compatibility with older servers, recipients should accept requests without this parameter, but MUST always send it. If this property @@ -389,7 +389,7 @@ The authorization parameters to include are: Unknown parameters are ignored. {{% boxes/note %}} -{{< changed-in v="1.11" >}} +{{% changed-in v="1.11" %}} This section used to reference [RFC 7235](https://datatracker.ietf.org/doc/html/rfc7235#section-2.1) and [RFC 7230](https://datatracker.ietf.org/doc/html/rfc9110#section-5.6.2), that were obsoleted by RFC 9110 without changes to the sections of interest here. @@ -1204,7 +1204,7 @@ Servers MUST use the server described in the [Matrix Content URI](/client-server Formatted as `mxc://{ServerName}/{MediaID}`, servers MUST download the media from `ServerName` using the below endpoints. -{{< changed-in v="1.11" >}} Servers were previously advised to use the `/_matrix/media/*` +{{% changed-in v="1.11" %}} Servers were previously advised to use the `/_matrix/media/*` endpoints described by the [Content Repository module in the Client-Server API](/client-server-api/#content-repository), however, those endpoints have been deprecated. New endpoints are introduced which require authentication. Naturally, as a server is not a user, they cannot provide diff --git a/data/api/client-server/content-repo.yaml b/data/api/client-server/content-repo.yaml index f50850bd..b6feba61 100644 --- a/data/api/client-server/content-repo.yaml +++ b/data/api/client-server/content-repo.yaml @@ -229,7 +229,7 @@ paths: {{% /boxes/note %}} {{% boxes/warning %}} - {{< changed-in v="1.11" >}} This endpoint MAY return `404 M_NOT_FOUND` + {{% changed-in v="1.11" %}} This endpoint MAY return `404 M_NOT_FOUND` for media which exists, but is after the server froze unauthenticated media access. See [Client Behaviour](/client-server-api/#content-repo-client-behaviour) for more information. @@ -303,7 +303,7 @@ paths: provided by the caller. {{% boxes/warning %}} - {{< changed-in v="1.11" >}} This endpoint MAY return `404 M_NOT_FOUND` + {{% changed-in v="1.11" %}} This endpoint MAY return `404 M_NOT_FOUND` for media which exists, but is after the server froze unauthenticated media access. See [Client Behaviour](/client-server-api/#content-repo-client-behaviour) for more information. @@ -375,7 +375,7 @@ paths: See the [Thumbnails](/client-server-api/#thumbnails) section for more information. {{% boxes/warning %}} - {{< changed-in v="1.11" >}} This endpoint MAY return `404 M_NOT_FOUND` + {{% changed-in v="1.11" %}} This endpoint MAY return `404 M_NOT_FOUND` for media which exists, but is after the server froze unauthenticated media access. See [Client Behaviour](/client-server-api/#content-repo-client-behaviour) for more information. diff --git a/meta/documentation_style.rst b/meta/documentation_style.rst index 6ed1b23a..1844f6ec 100644 --- a/meta/documentation_style.rst +++ b/meta/documentation_style.rst @@ -91,9 +91,6 @@ current version is `v1.1` then annotate your changes with `v1.2`. * `{{% added-in v="1.2" %}}` or `{{% changed-in v="1.2" %}}` within Markdown documents. * `x-addedInMatrixVersion` and `x-changedInMatrixVersion` within OpenAPI. -**Tip**: If you're trying to inline the Markdown version and getting unexpected results, -try replacing the `%` symbols with `<` and `>`, changing how Hugo renders the shortcode. - OpenAPI ~~~~~~~