Fix internal links

content/rooms/v1.md

@@ -155,7 +155,7 @@ The rules are as follows:
     1.  have duplicate entries for a given `type` and `state_key` pair
     2.  have entries whose `type` and `state_key` don't match those
         specified by the [auth events
-        selection](../server_server/%SERVER_RELEASE_LABEL%.html#auth-events-selection)
+        selection](/server-server-api#auth-events-selection)
         algorithm described in the server specification.
 3.  If event does not have a `m.room.create` in its `auth_events`,
     reject.
@@ -281,5 +281,5 @@ Events in version 1 rooms have the following structure:
 ### Canonical JSON
 
 Servers MUST NOT strictly enforce the JSON format specified in the
-[appendices](../appendices.html#canonical-json) for the reasons
+[appendices](/appendices#canonical-json) for the reasons
 described there.

content/rooms/v2.md

@@ -4,7 +4,7 @@ type: docs
 weight: 20
 ---
 
-This room version builds off of [version 1](v1.html) with an improved
+This room version builds off of [version 1](/rooms/v1) with an improved
 state resolution algorithm.
 
 ## Server implementation components
@@ -16,7 +16,7 @@ unaffected by the details contained here, and can safely ignore their
 presence.
 {{% /boxes/warning %}}
 
-Room version 2 uses the base components of [room version 1](v1.html),
+Room version 2 uses the base components of [room version 1](/rooms/v1),
 changing only the state resolution algorithm.
 
 ### State resolution
@@ -120,7 +120,7 @@ The *iterative auth checks algorithm* takes as input an initial room
 state and a sorted list of state events, and constructs a new room state
 by iterating through the event list and applying the state event to the
 room state if the state event is allowed by the [authorization
-rules](../server_server/%SERVER_RELEASE_LABEL%.html#authorization-rules).
+rules](/server-server-api#authorization-rules).
 If the state event is not allowed by the authorization rules, then the
 event is ignored. If a `(event_type, state_key)` key that is required
 for checking the authorization rules is not present in the state, then

content/rooms/v3.md

@@ -4,7 +4,7 @@ type: docs
 weight: 30
 ---
 
-This room version builds on [version 2](v2.html) with an improved event
+This room version builds on [version 2](/rooms/v2) with an improved event
 format.
 
 ## Client considerations
@@ -31,7 +31,7 @@ use cases should reference.
 {{% /boxes/warning %}}
 
 Room version 3 uses the state resolution algorithm defined in [room
-version 2](v2.html), and the event format defined here.
+version 2](/rooms/v2), and the event format defined here.
 
 ### Event IDs
 
@@ -46,9 +46,9 @@ hashes on an event to determine its ID.
 {{% /boxes/rationale %}}
 
 The event ID is the [reference
-hash](../server_server/%SERVER_RELEASE_LABEL%.html#reference-hashes) of
+hash](/server-server-api#calculating-the-reference-hash-for-an-event) of
 the event encoded using [Unpadded
-Base64](../appendices.html#unpadded-base64), prefixed with `$`. A
+Base64](/appendices#unpadded-base64), prefixed with `$`. A
 resulting event ID using this approach should look similar to
 `$CD66HAED5npg6074c6pDtLKalHjVfYb2q4Q3LZgrW6o`.
 
@@ -97,4 +97,4 @@ version due to the change in event format:
     power levels.
 
 The remaining rules are the same as [room version
-1](v1.html#authorization-rules).
+1](/rooms/v1#authorization-rules).

content/rooms/v4.md

@@ -4,7 +4,7 @@ type: docs
 weight: 40
 ---
 
-This room version builds on [version 3](v3.html) using a different
+This room version builds on [version 3](/rooms/v3) using a different
 encoding for event IDs.
 
 ## Client considerations
@@ -30,7 +30,7 @@ use cases should reference.
 {{% /boxes/warning %}}
 
 Room version 4 uses the same algorithms defined in [room version
-3](v3.html), however using URL-safe base64 to generate the event ID.
+3](/rooms/v3), however using URL-safe base64 to generate the event ID.
 
 ### Event IDs
 
@@ -43,9 +43,9 @@ generally made administration harder.
 {{% /boxes/rationale %}}
 
 The event ID is the [reference
-hash](../server_server/%SERVER_RELEASE_LABEL%.html#reference-hashes) of
+hash](/server-server-api#calculating-the-reference-hash-for-an-event) of
 the event encoded using a variation of [Unpadded
-Base64](../appendices.html#unpadded-base64) which replaces the 62nd and
+Base64](/appendices#unpadded-base64) which replaces the 62nd and
 63rd characters with `-` and `_` instead of using `+` and `/`. This
 matches [RFC4648's definition of URL-safe
 base64](https://tools.ietf.org/html/rfc4648#section-5). Event IDs are

content/rooms/v5.md

@@ -4,14 +4,14 @@ type: docs
 weight: 50
 ---
 
-This room version builds on [version 4](v4.html) while enforcing signing
+This room version builds on [version 4](/rooms/v4) while enforcing signing
 key validity periods for events.
 
 ## Client considerations
 
 There are no specific requirements for clients in this room version.
 Clients should be aware of event ID changes in [room version
-4](v4.html), however.
+4](/rooms/v4), however.
 
 ## Server implementation components
 
@@ -24,7 +24,7 @@ use cases should reference.
 {{% /boxes/warning %}}
 
 Room version 5 uses the same algorithms defined in [room version
-4](v4.html), ensuring that signing key validity is respected.
+4](/rooms/v4), ensuring that signing key validity is respected.
 
 ### Signing key validity period
 
@@ -32,9 +32,9 @@ When validating event signatures, servers MUST enforce the
 `valid_until_ts` property from a key request is at least as large as the
 `origin_server_ts` for the event being validated. Servers missing a copy
 of the signing key MUST try to obtain one via the [GET
-/\_matrix/key/v2/server](../server_server/%SERVER_RELEASE_LABEL%.html#get-matrix-key-v2-server-keyid)
+/\_matrix/key/v2/server](/server-server-api#get_matrixkeyv2serverkeyid)
 or [POST
-/\_matrix/key/v2/query](../server_server/%SERVER_RELEASE_LABEL%.html#post-matrix-key-v2-query)
+/\_matrix/key/v2/query](/server-server-api#post_matrixkeyv2query)
 APIs. When using the `/query` endpoint, servers MUST set the
 `minimum_valid_until_ts` property to prompt the notary server to attempt
 to refresh the key if appropriate.

content/rooms/v6.md

@@ -4,12 +4,12 @@ type: docs
 weight: 60
 ---
 
-This room version builds on [version 5](v5.html) while changing various
+This room version builds on [version 5](/rooms/v5) while changing various
 authorization rules performed on events.
 
 ## Client considerations
 
-The redaction algorithm has changed from [room version 1](v1.html) to
+The redaction algorithm has changed from [room version 1](/rooms/v1) to
 remove all rules against events of type `m.room.aliases`. Room versions
 2, 3, 4, and 5 all use v1's redaction algorithm. The algorithm is
 otherwise unchanged.
@@ -25,7 +25,7 @@ use cases should reference.
 {{% /boxes/warning %}}
 
 Room version 6 makes the following alterations to algorithms described
-in [room version 5](v5.html).
+in [room version 5](/rooms/v5).
 
 ### Redactions
 
@@ -71,13 +71,13 @@ follows:
     ...
 
 The remaining rules are the same as in [room version
-3](v3.html#authorization-rules-for-events) (the last inherited room
+3](/rooms/v3#authorization-rules-for-events) (the last inherited room
 version to specify the authorization rules).
 
 ### Canonical JSON
 
 Servers MUST strictly enforce the JSON format specified in the
-[appendices](../appendices.html#canonical-json). This translates to a
+[appendices](/appendices#canonical-json). This translates to a
 400 `M_BAD_JSON` error on most endpoints, or discarding of events over
 federation. For example, the Federation API's `/send` endpoint would
 discard the event whereas the Client Server API's `/send/{eventType}`