diff --git a/content/client-server-api/_index.md b/content/client-server-api/_index.md
index 0fd5f6b0..a05a0ed8 100644
--- a/content/client-server-api/_index.md
+++ b/content/client-server-api/_index.md
@@ -436,7 +436,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 +1350,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 +2342,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..ac41b76d 100644
--- a/content/client-server-api/modules/content_repo.md
+++ b/content/client-server-api/modules/content_repo.md
@@ -16,7 +16,7 @@ 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.
diff --git a/content/client-server-api/modules/guest_access.md b/content/client-server-api/modules/guest_access.md
index 86ac031a..9ececd7f 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:
@@ -57,7 +57,7 @@ for sending 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/receipts.md b/content/client-server-api/modules/receipts.md
index d8733e19..04db4494 100644
--- a/content/client-server-api/modules/receipts.md
+++ b/content/client-server-api/modules/receipts.md
@@ -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
diff --git a/content/client-server-api/modules/report_content.md b/content/client-server-api/modules/report_content.md
index 92288eee..2a203165 100644
--- a/content/client-server-api/modules/report_content.md
+++ b/content/client-server-api/modules/report_content.md
@@ -25,7 +25,7 @@ be legitimate.
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/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..e0362950 100644
--- a/content/rooms/v10.md
+++ b/content/rooms/v10.md
@@ -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..8a3566c4 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
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..6da5dfb8 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.
diff --git a/content/rooms/v7.md b/content/rooms/v7.md
index 2af07c16..9afec4bf 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.
@@ -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..683edde5 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