Add hyperlinks to endpoints (#2016)

... because there's nothing more infuriating than someone talking about an
endpoint, then having to search through 150 pages of spec for it.

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

@@ -16,7 +16,7 @@ data with the same `type`.
 The client receives the account data as events in the `account_data`
 sections of a [`/sync`](#get_matrixclientv3sync) response.
 
-These events can also be received in a `/events` response or in the
+These events can also be received in a [`/events`](#get_matrixclientv3events) response or in the
 `account_data` section of a room in a `/sync` response. `m.tag` events appearing in
 `/events` will have a `room_id` with the room the tags are for.
 

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

@@ -206,6 +206,6 @@ HTML page. Therefore, there is no risk in trusting the user-defined content type
 as long as the `Content-Disposition` is calculated based on that type.
 
 Clients SHOULD NOT rely on servers returning `inline` rather than `attachment`
-on `/download`. Server implementations might decide out of an abundance of
+on [`/download`](#get_matrixclientv1mediadownloadservernamemediaid). Server implementations might decide out of an abundance of
 caution that all downloads are responded to with `attachment`, regardless of
 content type - clients should not be surprised by this behaviour.

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

@@ -13,10 +13,10 @@ and servers can implement the ignoring of users.
 
 To ignore a user, effectively blocking them, the client should add the
 target user to the `m.ignored_user_list` event in their account data
-using [`/user/<user_id>/account_data/<type>`](/client-server-api/#put_matrixclientv3useruseridaccount_datatype). Once ignored, the client will no longer receive events sent by
+using [`/user/<user_id>/account_data/<type>`](#put_matrixclientv3useruseridaccount_datatype). Once ignored, the client will no longer receive events sent by
 that user, with the exception of state events. The client should either
 hide previous content sent by the newly ignored user or perform a new
-`/sync` with no previous token.
+[`/sync`](#get_matrixclientv3sync) with no previous token.
 
 Invites to new rooms by ignored users will not be sent to the client.
 The server may optionally reject the invite on behalf of the client.

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

@@ -1044,7 +1044,7 @@ messages they have received.
 ##### Receiving notifications
 
 Servers MUST include the number of unread notifications in a client's
-`/sync` stream, and MUST update it as it changes. Notifications are
+[`/sync`](#get_matrixclientv3sync) stream, and MUST update it as it changes. Notifications are
 determined by the push rules which apply to an event.
 
 For encrypted events, the homeserver has limited access to the event content
@@ -1091,7 +1091,7 @@ users in the room (excluding the sender). This may result in:
 * Generating a new number of unread notifications for the user.
 * Making a request to the configured push gateway.
 
-The updated notification count from a new event MUST appear in the same `/sync`
+The updated notification count from a new event MUST appear in the same [`/sync`](#get_matrixclientv3sync)
 response as the event itself.
 
 #### Push Gateway behaviour

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

@@ -41,7 +41,7 @@ Threaded read receipts are discussed in further detail [below](#threaded-read-re
 
 {{% changed-in v="1.4" %}} Altered to support threaded read receipts.
 
-In `/sync`, receipts are listed under the `ephemeral` array of events
+In [`/sync`](#get_matrixclientv3sync), receipts are listed under the `ephemeral` array of events
 for a given room. New receipts that come down the event streams are
 deltas which update existing mappings. Clients should replace older
 receipt acknowledgements based on `user_id`, `receipt_type`, and the

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

@@ -16,7 +16,7 @@ when the sticker image is clicked.
 #### Events
 
 Sticker events are received as a single `m.sticker` event in the
-`timeline` section of a room, in a `/sync`.
+`timeline` section of a room, in a [`/sync`](#get_matrixclientv3sync).
 
 {{% event event="m.sticker" %}}
 

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

@@ -5,7 +5,7 @@ This module adds in support for inviting new members to a room where
 their Matrix user ID is not known, instead addressing them by a third-party
 identifier such as an email address. There are two flows here; one
 if a Matrix user ID is known for the third-party identifier, and one if
-not. Either way, the client calls `/invite` with the details of the
+not. Either way, the client calls [`/invite`](#post_matrixclientv3roomsroomidinvite) with the details of the
 third-party identifier.
 
 The homeserver asks the identity server whether a Matrix user ID is
@@ -37,7 +37,7 @@ A client asks a server to invite a user by their third-party identifier.
 
 #### Server behaviour
 
-Upon receipt of an `/invite`, the server is expected to look up the
+Upon receipt of an [`/invite`](#post_matrixclientv3roomsroomidinvite), the server is expected to look up the
 third-party identifier with the provided identity server. If the lookup
 yields a result for a Matrix User ID then the normal invite process can
 be initiated. This process ends up looking like this:
@@ -186,9 +186,9 @@ residents of the room while H3 is attempting to join.
 
 Note that when H1 sends the `m.room.member` event to H2 and H3 it does
 not have to block on either server's receipt of the event. Likewise, H1
-may complete the `/exchange_third_party_invite/:roomId` request at the
+may complete the [`/exchange_third_party_invite`](/server-server-api/#put_matrixfederationv1exchange_third_party_inviteroomid) request at the
 same time as sending the `m.room.member` event to H2 and H3.
-Additionally, H3 may complete the `/3pid/onbind` request it got from IS
+Additionally, H3 may complete the [`/3pid/onbind`](/server-server-api/#put_matrixfederationv13pidonbind) request it got from IS
 at any time - the completion is not shown in the diagram.
 
 H1 MUST verify the request from H3 to ensure the `signed` property is