Update client-server API endpoints to move from r0 to v3 (plus whites…

…pace fixes) (#3421)

* Blind find & replace all on client major version -> v3

* Fix up bad replacements

* Fix anchors for r0->v3

* Changelog

changelogs/client_server/newsfragments/3421.feature

@@ -0,0 +1 @@
+Re-version all endpoints to be `v3` as a starting point instead of `r0` as per [MSC2844](https://github.com/matrix-org/matrix-doc/pull/2844).

content/application-service-api.md

@@ -271,11 +271,11 @@ should identify itself to the Client-Server API by providing its
 `as_token` for the `access_token` alongside the user the application
 service would like to masquerade as.
 
-Inputs:  
+Inputs:
 -   Application service token (`as_token`)
 -   User ID in the AS namespace to act as.
 
-Notes:  
+Notes:
 -   This applies to all aspects of the Client-Server API, except for
     Account Management.
 -   The `as_token` is inserted into `access_token` which is usually
@@ -295,7 +295,7 @@ by the `sender_localpart` property of the registration.
 
 An example request would be:
 
-    GET /_matrix/client/%CLIENT_MAJOR_VERSION%/account/whoami?user_id=@_irc_user:example.org
+    GET /_matrix/client/v3/account/whoami?user_id=@_irc_user:example.org
     Authorization: Bearer YourApplicationServiceTokenHere
 
 #### Timestamp massaging
@@ -325,7 +325,7 @@ achieved by including the `as_token` on a `/register` request, along
 with a login type of `m.login.application_service` to set the desired
 user ID without a password.
 
-    POST /_matrix/client/%CLIENT_MAJOR_VERSION%/register
+    POST /_matrix/client/v3/register
     Authorization: Bearer YourApplicationServiceTokenHere
 
     Content:

content/client-server-api/_index.md

@@ -799,7 +799,7 @@ type, it can direct the user to a web browser with the URL of a fallback
 page which will allow the user to complete that login step out-of-band
 in their web browser. The URL it should open is:
 
-    /_matrix/client/%CLIENT_MAJOR_VERSION%/auth/<auth type>/fallback/web?session=<session ID>
+    /_matrix/client/v3/auth/<auth type>/fallback/web?session=<session ID>
 
 Where `auth type` is the type name of the stage it is attempting and
 `session ID` is the ID of the session given by the homeserver.
@@ -843,7 +843,7 @@ window which will handle unknown login types:
  *     homeserverUrl: the base url of the homeserver (e.g. "https://matrix.org")
  *
  *     apiEndpoint: the API endpoint being used (e.g.
- *        "/_matrix/client/%CLIENT_MAJOR_VERSION%/account/password")
+ *        "/_matrix/client/v3/account/password")
  *
  *     loginType: the loginType being attempted (e.g. "m.login.recaptcha")
  *
@@ -879,7 +879,7 @@ function unknownLoginType(homeserverUrl, apiEndpoint, loginType, sessionID, onCo
     window.addEventListener("message", eventListener);
 
     var url = homeserverUrl +
-        "/_matrix/client/%CLIENT_MAJOR_VERSION%/auth/" +
+        "/_matrix/client/v3/auth/" +
         encodeURIComponent(loginType) +
         "/fallback/web?session=" +
         encodeURIComponent(sessionID);
@@ -1142,7 +1142,7 @@ Some examples of what should **not** be a capability are:
 -   Whether the server supports a feature in the `unstable`
     specification.
 -   Media size limits - these are handled by the
-    `/media/%CLIENT_MAJOR_VERSION%/config` API.
+    [`/config`](#get_matrixmediav3config) API.
 -   Optional encodings or alternative transports for communicating with
     the server.
 
@@ -1271,9 +1271,9 @@ The expected pattern for using lazy-loading is currently:
 
 The current endpoints which support lazy-loading room members are:
 
--   [`/sync`](/client-server-api/#get_matrixclientr0sync)
--   [`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientr0roomsroomidmessages)
--   [`/rooms/{roomId}/context/{eventId}`](/client-server-api/#get_matrixclientr0roomsroomidcontexteventid)
+-   [`/sync`](/client-server-api/#get_matrixclientv3sync)
+-   [`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientv3roomsroomidmessages)
+-   [`/rooms/{roomId}/context/{eventId}`](/client-server-api/#get_matrixclientv3roomsroomidcontexteventid)
 
 ### API endpoints
 
@@ -1419,13 +1419,13 @@ events.
 ### Syncing
 
 To read events, the intended flow of operation is for clients to first
-call the [`/sync`](/client-server-api/#get_matrixclientr0sync) API without a `since` parameter. This returns the
+call the [`/sync`](/client-server-api/#get_matrixclientv3sync) API without a `since` parameter. This returns the
 most recent message events for each room, as well as the state of the
 room at the start of the returned timeline. The response also includes a
 `next_batch` field, which should be used as the value of the `since`
 parameter in the next call to `/sync`. Finally, the response includes,
 for each room, a `prev_batch` field, which can be passed as a `start`
-parameter to the [`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientr0roomsroomidmessages) API to retrieve earlier
+parameter to the [`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientv3roomsroomidmessages) API to retrieve earlier
 messages.
 
 You can visualise the range of events being returned as:
@@ -1462,7 +1462,7 @@ containing only the most recent message events. A state "delta" is also
 returned, summarising any state changes in the omitted part of the
 timeline. The client may therefore end up with "gaps" in its knowledge
 of the message timeline. The client can fill these gaps using the
-[`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientr0roomsroomidmessages) API. This situation looks like this:
+[`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientv3roomsroomidmessages) API. This situation looks like this:
 
 ```
     | gap |
@@ -1593,8 +1593,8 @@ some events cannot be simply deleted, e.g. membership events, we instead
 not required by the protocol. This stripped down event is thereafter
 returned anytime a client or remote server requests it. Redacting an
 event cannot be undone, allowing server owners to delete the offending
-content from the databases. Servers should include a copy of the 
-`m.room.redaction` event under `unsigned` as `redacted_because` 
+content from the databases. Servers should include a copy of the
+`m.room.redaction` event under `unsigned` as `redacted_because`
 when serving the redacted event to clients.
 
 The exact algorithm to apply against an event is defined in the [room
@@ -1786,7 +1786,7 @@ must have been invited to or have joined the room before they are
 eligible to leave the room. Leaving a room to which the user has been
 invited rejects the invite, and can retract a knock. Once a user leaves
 a room, it will no longer appear in the response to the
-[`/sync`](/client-server-api/#get_matrixclientr0sync) API unless it is
+[`/sync`](/client-server-api/#get_matrixclientv3sync) API unless it is
 explicitly requested via a filter with the `include_leave` field set
 to `true`.
 
@@ -1795,7 +1795,7 @@ Whether or not they actually joined the room, if the room is an
 re-join the room.
 
 A user can also forget a room which they have left. Rooms which have
-been forgotten will never appear the response to the [`/sync`](/client-server-api/#get_matrixclientr0sync) API,
+been forgotten will never appear the response to the [`/sync`](/client-server-api/#get_matrixclientv3sync) API,
 until the user re-joins, is re-invited, or knocks.
 
 A user may wish to force another user to leave a room. This can be done
@@ -1816,7 +1816,7 @@ target user to leave the room and prevents them from re-joining the
 room. A banned user will not be treated as a joined user, and so will
 not be able to send or receive events in the room. In order to ban
 someone, the user performing the ban MUST have the required power level.
-To ban a user, a request should be made to [`/rooms/<room_id>/ban`](/client-server-api/#post_matrixclientr0roomsroomidban)
+To ban a user, a request should be made to [`/rooms/<room_id>/ban`](/client-server-api/#post_matrixclientv3roomsroomidban)
 with:
 
 ```json
@@ -1838,7 +1838,7 @@ target member's state, by making a request to
 ```
 
 A user must be explicitly unbanned with a request to
-[`/rooms/<room_id>/unban`](/client-server-api/#post_matrixclientr0roomsroomidunban) before they can re-join the room or be
+[`/rooms/<room_id>/unban`](/client-server-api/#post_matrixclientv3roomsroomidunban) before they can re-join the room or be
 re-invited.
 
 {{% http-api spec="client-server" api="banning" %}}

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

@@ -24,7 +24,7 @@ whether a chat is 'direct' to an invitee.
 #### Client behaviour
 
 To start a direct chat with another user, the inviting user's client
-should set the `is_direct` flag to [`/createRoom`](/client-server-api/#post_matrixclientr0createroom). The client should do this
+should set the `is_direct` flag to [`/createRoom`](/client-server-api/#post_matrixclientv3createroom). The client should do this
 whenever the flow the user has followed is one where their intention is
 to speak directly with another person, as opposed to bringing that
 person in to a shared room. For example, clicking on 'Start Chat' beside
@@ -38,10 +38,10 @@ the flag altogether.
 
 Both the inviting client and the invitee's client should record the fact
 that the room is a direct chat by storing an `m.direct` event in the
-account data using [`/user/<user_id>/account_data/<type>`](/client-server-api/#put_matrixclientr0useruseridaccount_datatype).
+account data using [`/user/<user_id>/account_data/<type>`](/client-server-api/#put_matrixclientv3useruseridaccount_datatype).
 
 #### Server behaviour
 
-When the `is_direct` flag is given to [`/createRoom`](/client-server-api/#post_matrixclientr0createroom), the home server must set the
+When the `is_direct` flag is given to [`/createRoom`](/client-server-api/#post_matrixclientv3createroom), the home server must set the
 `is_direct` flag in the invite member event for any users invited in the
-[`/createRoom`](/client-server-api/#post_matrixclientr0createroom) call.
+[`/createRoom`](/client-server-api/#post_matrixclientv3createroom) call.

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

@@ -113,13 +113,13 @@ key, and a number of signed Curve25519 one-time keys.
 ##### Uploading keys
 
 A device uploads the public parts of identity keys to their homeserver
-as a signed JSON object, using the [`/keys/upload`](/client-server-api/#post_matrixclientr0keysupload) API. The JSON object
+as a signed JSON object, using the [`/keys/upload`](/client-server-api/#post_matrixclientv3keysupload) API. The JSON object
 must include the public part of the device's Ed25519 key, and must be
 signed by that key, as described in [Signing
 JSON](/appendices/#signing-json).
 
 One-time keys are also uploaded to the homeserver using the
-[`/keys/upload`](/client-server-api/#post_matrixclientr0keysupload) API.
+[`/keys/upload`](/client-server-api/#post_matrixclientv3keysupload) API.
 
 Devices must store the private part of each key they upload. They can
 discard the private part of a one-time key when they receive a message
@@ -134,12 +134,12 @@ too many private keys may discard keys starting with the oldest.
 Before Alice can send an encrypted message to Bob, she needs a list of
 each of his devices and the associated identity keys, so that she can
 establish an encryption session with each device. This list can be
-obtained by calling [`/keys/query`](/client-server-api/#post_matrixclientr0keysquery), passing Bob's user ID in the
+obtained by calling [`/keys/query`](/client-server-api/#post_matrixclientv3keysquery), passing Bob's user ID in the
 `device_keys` parameter.
 
 From time to time, Bob may add new devices, and Alice will need to know
 this so that she can include his new devices for later encrypted
-messages. A naive solution to this would be to call [`/keys/query`](/client-server-api/#post_matrixclientr0keysquery)
+messages. A naive solution to this would be to call [`/keys/query`](/client-server-api/#post_matrixclientv3keysquery)
 before sending each message -however, the number of users and devices
 may be large and this would be inefficient.
 
@@ -157,23 +157,23 @@ process:
     list, and a separate flag to indicate that its list of Bob's devices
     is outdated. Both flags should be in storage which persists over
     client restarts.
-2.  It then makes a request to [`/keys/query`](/client-server-api/#post_matrixclientr0keysquery), passing Bob's user ID in
+2.  It then makes a request to [`/keys/query`](/client-server-api/#post_matrixclientv3keysquery), passing Bob's user ID in
     the `device_keys` parameter. When the request completes, it stores
     the resulting list of devices in persistent storage, and clears the
     'outdated' flag.
-3.  During its normal processing of responses to [`/sync`](/client-server-api/#get_matrixclientr0sync), Alice's client
+3.  During its normal processing of responses to [`/sync`](/client-server-api/#get_matrixclientv3sync), Alice's client
     inspects the `changed` property of the [`device_lists`](/client-server-api/#extensions-to-sync-1) field. If it
     is tracking the device lists of any of the listed users, then it
     marks the device lists for those users outdated, and initiates
-    another request to [`/keys/query`](/client-server-api/#post_matrixclientr0keysquery) for them.
+    another request to [`/keys/query`](/client-server-api/#post_matrixclientv3keysquery) for them.
 4.  Periodically, Alice's client stores the `next_batch` field of the
-    result from [`/sync`](/client-server-api/#get_matrixclientr0sync) in persistent storage. If Alice later restarts her
+    result from [`/sync`](/client-server-api/#get_matrixclientv3sync) in persistent storage. If Alice later restarts her
     client, it can obtain a list of the users who have updated their
-    device list while it was offline by calling [`/keys/changes`](/client-server-api/#get_matrixclientr0keyschanges),
+    device list while it was offline by calling [`/keys/changes`](/client-server-api/#get_matrixclientv3keyschanges),
     passing the recorded `next_batch` field as the `from` parameter. If
     the client is tracking the device list of any of the users listed in
     the response, it marks them as outdated. It combines this list with
-    those already flagged as outdated, and initiates a [`/keys/query`](/client-server-api/#post_matrixclientr0keysquery)
+    those already flagged as outdated, and initiates a [`/keys/query`](/client-server-api/#post_matrixclientv3keysquery)
     request for all of them.
 
 {{% boxes/warning %}}
@@ -339,7 +339,7 @@ Example:
 
 A client wanting to set up a session with another device can claim a
 one-time key for that device. This is done by making a request to the
-[`/keys/claim`](/client-server-api/#post_matrixclientr0keysclaim) API.
+[`/keys/claim`](/client-server-api/#post_matrixclientv3keysclaim) API.
 
 A homeserver should rate-limit the number of one-time keys that a given
 user or remote server can claim. A homeserver should discard the public
@@ -860,11 +860,11 @@ 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
-/\_matrix/client/r0/keys/device\_signing/upload](/client-server-api/#post_matrixclientr0keysdevice_signingupload). When Alice uploads
+/\_matrix/client/r0/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`
 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/r0/keys/query](/client-server-api/#post_matrixclientr0keysquery)
+ID in his `/sync`, he will call [POST /\_matrix/client/r0/keys/query](/client-server-api/#post_matrixclientv3keysquery)
 to retrieve Alice's device and cross-signing keys.
 
 If Alice has a device and wishes to send an encrypted message to Bob,
@@ -1166,17 +1166,17 @@ However, as the session keys are stored on the server encrypted, it
 requires users to enter a decryption key to decrypt the session keys.
 
 To create a backup, a client will call [POST
-/\_matrix/client/r0/room\_keys/version](#post_matrixclientr0room_keysversion) and define how the keys are to
+/\_matrix/client/r0/room\_keys/version](#post_matrixclientv3room_keysversion) and define how the keys are to
 be encrypted through the backup's `auth_data`; other clients can
 discover the backup by calling [GET
-/\_matrix/client/r0/room\_keys/version](#get_matrixclientr0room_keysversion). Keys are encrypted according
+/\_matrix/client/r0/room\_keys/version](#get_matrixclientv3room_keysversion). Keys are encrypted according
 to the backup's `auth_data` and added to the backup by calling [PUT
-/\_matrix/client/r0/room\_keys/keys](#put_matrixclientr0room_keyskeys) or one of its variants, and can
-be retrieved by calling [GET /\_matrix/client/r0/room\_keys/keys](#get_matrixclientr0room_keyskeys) or
+/\_matrix/client/r0/room\_keys/keys](#put_matrixclientv3room_keyskeys) or one of its variants, and can
+be retrieved by calling [GET /\_matrix/client/r0/room\_keys/keys](#get_matrixclientv3room_keyskeys) or
 one of its variants. Keys can only be written to the most recently
 created version of the backup. Backups can also be deleted using [DELETE
-/\_matrix/client/r0/room\_keys/version/{version}](#delete_matrixclientr0room_keysversionversion), or individual keys
-can be deleted using [DELETE /\_matrix/client/r0/room\_keys/keys](#delete_matrixclientr0room_keyskeys) or
+/\_matrix/client/r0/room\_keys/version/{version}](#delete_matrixclientv3room_keysversionversion), or individual keys
+can be deleted using [DELETE /\_matrix/client/r0/room\_keys/keys](#delete_matrixclientv3room_keyskeys) or
 one of its variants.
 
 Clients must only store keys in backups after they have ensured that the
@@ -1458,7 +1458,7 @@ correspond to the user who sent the event, `recipient` to the local
 user, and `recipient_keys` to the local ed25519 key.
 
 Clients must confirm that the `sender_key` and the `ed25519` field value
-under the `keys` property match the keys returned by [`/keys/query`](/client-server-api/#post_matrixclientr0keysquery) for
+under the `keys` property match the keys returned by [`/keys/query`](/client-server-api/#post_matrixclientv3keysquery) for
 the given user, and must also verify the signature of the payload.
 Without this check, a client cannot be sure that the sender device owns
 the private part of the ed25519 key it claims to have in the Olm
@@ -1590,17 +1590,17 @@ messages.
 
 ##### Extensions to /sync
 
-This module adds an optional `device_lists` property to the [`/sync`](/client-server-api/#get_matrixclientr0sync)  response,
+This module adds an optional `device_lists` property to the [`/sync`](/client-server-api/#get_matrixclientv3sync)  response,
 as specified below. The server need only populate this property for an
 incremental `/sync` (i.e., one where the `since` parameter was
-specified). The client is expected to use [`/keys/query`](/client-server-api/#post_matrixclientr0keysquery) or
-[`/keys/changes`](/client-server-api/#get_matrixclientr0keyschanges) for the equivalent functionality after an initial
+specified). The client is expected to use [`/keys/query`](/client-server-api/#post_matrixclientv3keysquery) or
+[`/keys/changes`](/client-server-api/#get_matrixclientv3keyschanges) for the equivalent functionality after an initial
 sync, as documented in [Tracking the device list for a
 user](#tracking-the-device-list-for-a-user).
 
 It also adds a `one_time_keys_count` property. Note the spelling
 difference with the `one_time_key_counts` property in the
-[`/keys/upload`](/client-server-api/#post_matrixclientr0keysupload) response.
+[`/keys/upload`](/client-server-api/#post_matrixclientv3keysupload) response.
 
 | Parameter                  | Type               | Description                                                                                                            |
 |----------------------------|--------------------|------------------------------------------------------------------------------------------------------------------------|