From 52f5e73a3941a74850921243d7283ab5d60436c8 Mon Sep 17 00:00:00 2001 From: Will Date: Fri, 29 Jan 2021 15:32:31 -0800 Subject: [PATCH] Update content to call the new template for HTTP APIs --- content/application-service-api.md | 10 ++-- content/client-server-api/_index.md | 56 +++++++++---------- .../client-server-api/modules/account_data.md | 2 +- content/client-server-api/modules/admin.md | 2 +- .../client-server-api/modules/content_repo.md | 2 +- .../modules/device_management.md | 2 +- .../modules/end_to_end_encryption.md | 6 +- .../modules/event_context.md | 2 +- content/client-server-api/modules/openid.md | 2 +- content/client-server-api/modules/presence.md | 2 +- content/client-server-api/modules/push.md | 6 +- .../client-server-api/modules/read_markers.md | 2 +- content/client-server-api/modules/receipts.md | 2 +- .../modules/report_content.md | 2 +- .../modules/room_previews.md | 2 +- .../modules/room_upgrades.md | 2 +- content/client-server-api/modules/search.md | 2 +- .../modules/send_to_device.md | 2 +- .../client-server-api/modules/sso_login.md | 2 +- content/client-server-api/modules/tags.md | 2 +- .../modules/third_party_invites.md | 2 +- .../modules/third_party_networks.md | 2 +- .../modules/typing_notifications.md | 2 +- .../client-server-api/modules/voip_events.md | 2 +- content/identity-service-api.md | 36 ++++++------ content/push-gateway-api.md | 2 +- content/server-server-api.md | 40 ++++++------- 27 files changed, 98 insertions(+), 98 deletions(-) diff --git a/content/application-service-api.md b/content/application-service-api.md index 13d43883..e324bba0 100644 --- a/content/application-service-api.md +++ b/content/application-service-api.md @@ -204,7 +204,7 @@ NOT alter (e.g. add more) events they were going to send within that transaction ID on retries, as the application service may have already processed the events. -{{transactions\_as\_http\_api}} +{{% http-api spec="application-service" api="transactions" %}} #### Querying @@ -227,9 +227,9 @@ about information about the entity such as room ID to room alias mappings. {{% /boxes/rationale %}} -{{query\_user\_as\_http\_api}} +{{% http-api spec="application-service" api="query_user" %}} -{{query\_room\_as\_http\_api}} +{{% http-api spec="application-service" api="query_room" %}} #### Third party networks @@ -251,7 +251,7 @@ request the homeserver to search in a particular "network" (protocol), the search fields will be passed along to the application service for filtering. -{{protocols\_as\_http\_api}} +{{% http-api spec="application-service" api="protocols" %}} ### Client-Server API Extensions @@ -356,7 +356,7 @@ defined third party protocols. These room directories may be accessed by clients through additional parameters on the `/publicRooms` client-server endpoint. -{{appservice\_room\_directory\_cs\_http\_api}} +{{% http-api spec="client-server" api="appservice_room_directory" %}} ### Referencing messages from a third party network diff --git a/content/client-server-api/_index.md b/content/client-server-api/_index.md index b6a0b075..2a4ba3b9 100644 --- a/content/client-server-api/_index.md +++ b/content/client-server-api/_index.md @@ -205,7 +205,7 @@ Some API endpoints may allow or require the use of `POST` requests without a transaction ID. Where this is optional, the use of a `PUT` request is strongly recommended. -{{versions\_cs\_http\_api}} +{{% http-api spec="client-server" api="versions" %}} ## Web Browser Clients @@ -301,7 +301,7 @@ specify parameter values. The flow for this method is as follows: `m.identity_server` property is present, but does not have a `base_url` value, then `FAIL_ERROR`. -{{wellknown\_cs\_http\_api}} +{{% http-api spec="client-server" api="wellknown" %}} ## Client Authentication @@ -1021,9 +1021,9 @@ 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`. -{{login\_cs\_http\_api}} +{{% http-api spec="client-server" api="login" %}} -{{logout\_cs\_http\_api}} +{{% http-api spec="client-server" api="logout" %}} #### Login Fallback @@ -1044,7 +1044,7 @@ the login endpoint during the login process. For example: ### Account registration and management -{{registration\_cs\_http\_api}} +{{% http-api spec="client-server" api="registration" %}} #### Notes on password management @@ -1069,11 +1069,11 @@ identifier that is found in an identity server. Note that an identifier can be added and bound at the same time, depending on context. {{% /boxes/note %}} -{{administrative\_contact\_cs\_http\_api}} +{{% http-api spec="client-server" api="administrative_contact" %}} ### Current account information -{{whoami\_cs\_http\_api}} +{{% http-api spec="client-server" api="whoami" %}} #### Notes on identity servers @@ -1148,7 +1148,7 @@ Matrix specification while other values may be used by servers using the Java package naming convention. The capabilities supported by the Matrix specification are defined later in this section. -{{capabilities\_cs\_http\_api}} +{{% http-api spec="client-server" api="capabilities" %}} ### `m.change_password` capability @@ -1356,7 +1356,7 @@ The current endpoints which support lazy-loading room members are: ### API endpoints -{{filter\_cs\_http\_api}} +{{% http-api spec="client-server" api="filter" %}} ## Events @@ -1582,23 +1582,23 @@ take a copy of the state dictionary, and *rewind* S1, in order to correctly calculate the display name for M0. {{% /boxes/rationale %}} -{{sync\_cs\_http\_api}} +{{% http-api spec="client-server" api="sync" %}} -{{old\_sync\_cs\_http\_api}} +{{% http-api spec="client-server" api="old_sync" %}} ### Getting events for a room There are several APIs provided to `GET` events for a room: -{{rooms\_cs\_http\_api}} +{{% http-api spec="client-server" api="rooms" %}} -{{message\_pagination\_cs\_http\_api}} +{{% http-api spec="client-server" api="message_pagination" %}} -{{room\_initial\_sync\_cs\_http\_api}} +{{% http-api spec="client-server" api="room_initial_sync" %}} ### Sending events to a room -{{room\_state\_cs\_http\_api}} +{{% http-api spec="client-server" api="room_state" %}} **Examples** @@ -1647,7 +1647,7 @@ PUT /rooms/!roomid:domain/state/m.room.bgd.color { "color": "red", "hex": "#ff0000" } ``` -{{room\_send\_cs\_http\_api}} +{{% http-api spec="client-server" api="room_send" %}} ### Redactions @@ -1686,7 +1686,7 @@ the topic to be removed from the room. #### Client behaviour -{{redaction\_cs\_http\_api}} +{{% http-api spec="client-server" api="redaction" %}} ## Rooms @@ -1706,7 +1706,7 @@ permissions in this room. This includes: See [Room Events](#room-events) for more information on these events. To create a room, a client has to use the following API. -{{create\_room\_cs\_http\_api}} +{{% http-api spec="client-server" api="create_room" %}} ### Room aliases @@ -1731,7 +1731,7 @@ have a room alias of `#alias:example.com`, this SHOULD be checked to make sure that the room's ID matches the `room_id` returned from the request. -{{directory\_cs\_http\_api}} +{{% http-api spec="client-server" api="directory" %}} ### Permissions @@ -1816,13 +1816,13 @@ The allowable state transitions of membership are: /ban ``` -{{list\_joined\_rooms\_cs\_http\_api}} +{{% http-api spec="client-server" api="list_joined_rooms" %}} #### Joining rooms -{{inviting\_cs\_http\_api}} +{{% http-api spec="client-server" api="inviting" %}} -{{joining\_cs\_http\_api}} +{{% http-api spec="client-server" api="joining" %}} #### Leaving rooms @@ -1848,9 +1848,9 @@ behaviour is the same as if they had left of their own accord. In particular, the user is free to re-join if the room is not "invite-only". -{{leaving\_cs\_http\_api}} +{{% http-api spec="client-server" api="leaving" %}} -{{kicking\_cs\_http\_api}} +{{% http-api spec="client-server" api="kicking" %}} ##### Banning users in a room @@ -1884,21 +1884,21 @@ A user must be explicitly unbanned with a request to `/rooms//unban`\_ before they can re-join the room or be re-invited. -{{banning\_cs\_http\_api}} +{{% http-api spec="client-server" api="banning" %}} ### Listing rooms -{{list\_public\_rooms\_cs\_http\_api}} +{{% http-api spec="client-server" api="list_public_rooms" %}} ## User Data ### User Directory -{{users\_cs\_http\_api}} +{{% http-api spec="client-server" api="users" %}} ### Profiles -{{profile\_cs\_http\_api}} +{{% http-api spec="client-server" api="profile" %}} #### Events on Change of Profile Information diff --git a/content/client-server-api/modules/account_data.md b/content/client-server-api/modules/account_data.md index ea78dc82..2ae34686 100644 --- a/content/client-server-api/modules/account_data.md +++ b/content/client-server-api/modules/account_data.md @@ -23,7 +23,7 @@ These events can also be received in a `/events` response or in the #### Client Behaviour -{{account\_data\_cs\_http\_api}} +{{% http-api spec="client-server" api="account-data" %}} #### Server Behaviour diff --git a/content/client-server-api/modules/admin.md b/content/client-server-api/modules/admin.md index 28176bd9..1f0cbe22 100644 --- a/content/client-server-api/modules/admin.md +++ b/content/client-server-api/modules/admin.md @@ -10,4 +10,4 @@ server state and data. #### Client Behaviour -{{admin\_cs\_http\_api}} +{{% http-api spec="client-server" api="admin" %}} diff --git a/content/client-server-api/modules/content_repo.md b/content/client-server-api/modules/content_repo.md index f615e7f7..fba296a0 100644 --- a/content/client-server-api/modules/content_repo.md +++ b/content/client-server-api/modules/content_repo.md @@ -34,7 +34,7 @@ look like: Clients can upload and download content using the following HTTP APIs. -{{content\_repo\_cs\_http\_api}} +{{% http-api spec="client-server" api="content-repo" %}} ##### Thumbnails diff --git a/content/client-server-api/modules/device_management.md b/content/client-server-api/modules/device_management.md index c6fa6c45..2cf93f45 100644 --- a/content/client-server-api/modules/device_management.md +++ b/content/client-server-api/modules/device_management.md @@ -13,7 +13,7 @@ Clients that implement this module should offer the user a list of registered devices, as well as the means to update their display names. Clients should also allow users to delete disused devices. -{{device\_management\_cs\_http\_api}} +{{% http-api spec="client-server" api="device_management" %}} #### Security considerations diff --git a/content/client-server-api/modules/end_to_end_encryption.md b/content/client-server-api/modules/end_to_end_encryption.md index d8d1051c..b3efaeb2 100644 --- a/content/client-server-api/modules/end_to_end_encryption.md +++ b/content/client-server-api/modules/end_to_end_encryption.md @@ -905,7 +905,7 @@ To avoid leaking of social graphs, servers will only allow users to see: Users will not be able to see signatures made by other users' user-signing keys. -{{cross\_signing\_cs\_http\_api}} +{{% http-api spec="client-server" api="cross_signing" %}} #### Sharing keys between devices @@ -1050,7 +1050,7 @@ The `session_data` field in the backups is constructed as follows: the resulting MAC are base64-encoded, and become the `mac` property of the `session_data`. -{{key\_backup\_cs\_http\_api}} +{{% http-api spec="client-server" api="key_backup" %}} ##### Key exports @@ -1369,7 +1369,7 @@ messages. ##### Key management API -{{keys\_cs\_http\_api}} +{{% http-api spec="client-server" api="keys" %}} ##### Extensions to /sync diff --git a/content/client-server-api/modules/event_context.md b/content/client-server-api/modules/event_context.md index 32d7b9e8..65b1a7a4 100644 --- a/content/client-server-api/modules/event_context.md +++ b/content/client-server-api/modules/event_context.md @@ -14,7 +14,7 @@ an event. There is a single HTTP API for retrieving event context, documented below. -{{event\_context\_cs\_http\_api}} +{{% http-api spec="client-server" api="event_context" %}} #### Security considerations diff --git a/content/client-server-api/modules/openid.md b/content/client-server-api/modules/openid.md index af8b31c9..c51591fe 100644 --- a/content/client-server-api/modules/openid.md +++ b/content/client-server-api/modules/openid.md @@ -10,4 +10,4 @@ service. The third party service does need to be matrix-aware in that it will need to know to resolve matrix homeservers to exchange the user's token for identity information. -{{openid\_cs\_http\_api}} +{{% http-api spec="client-server" api="openid" %}} diff --git a/content/client-server-api/modules/presence.md b/content/client-server-api/modules/presence.md index 83f9c560..683d4839 100644 --- a/content/client-server-api/modules/presence.md +++ b/content/client-server-api/modules/presence.md @@ -37,7 +37,7 @@ enum of one of the following: Clients can manually set/get their presence using the HTTP APIs listed below. -{{presence\_cs\_http\_api}} +{{% http-api spec="client-server" api="presence" %}} ##### Last active ago diff --git a/content/client-server-api/modules/push.md b/content/client-server-api/modules/push.md index 00b24cb4..16e9ad71 100644 --- a/content/client-server-api/modules/push.md +++ b/content/client-server-api/modules/push.md @@ -90,7 +90,7 @@ Clients MUST configure a Pusher before they will receive push notifications. There is a single API endpoint for this, as described below. -{{pusher\_cs\_http\_api}} +{{% http-api spec="client-server" api="pusher" %}} ##### Listing Notifications @@ -98,7 +98,7 @@ A client can retrieve a list of events that it has been notified about. This may be useful so that users can see a summary of what important messages they have received. -{{notifications\_cs\_http\_api}} +{{% http-api spec="client-server" api="notifications" %}} ##### Receiving notifications @@ -658,7 +658,7 @@ Definition: Clients can retrieve, add, modify and remove push rules globally or per-device using the APIs below. -{{pushrules\_cs\_http\_api}} +{{% http-api spec="client-server" api="pushrules" %}} ##### Push Rules: Events diff --git a/content/client-server-api/modules/read_markers.md b/content/client-server-api/modules/read_markers.md index ccbafd26..d2738821 100644 --- a/content/client-server-api/modules/read_markers.md +++ b/content/client-server-api/modules/read_markers.md @@ -39,7 +39,7 @@ commonly updated at the same time, and therefore the client might wish to save an extra HTTP call. Providing an `m.read` location performs the same task as a request to `/receipt/m.read/$event:example.org`. -{{read\_markers\_cs\_http\_api}} +{{% http-api spec="client-server" api="read_markers" %}} #### Server behaviour diff --git a/content/client-server-api/modules/receipts.md b/content/client-server-api/modules/receipts.md index 423decea..05ea5ca1 100644 --- a/content/client-server-api/modules/receipts.md +++ b/content/client-server-api/modules/receipts.md @@ -58,7 +58,7 @@ for events sent by their own user. A client can update the markers for its user by interacting with the following HTTP APIs. -{{receipts\_cs\_http\_api}} +{{% http-api spec="client-server" api="receipts" %}} #### Server behaviour diff --git a/content/client-server-api/modules/report_content.md b/content/client-server-api/modules/report_content.md index ff90207d..c6157f3c 100644 --- a/content/client-server-api/modules/report_content.md +++ b/content/client-server-api/modules/report_content.md @@ -14,7 +14,7 @@ offensive" and 0 is "inoffensive". #### Client behaviour -{{report\_content\_cs\_http\_api}} +{{% http-api spec="client-server" api="report_content" %}} #### Server behaviour diff --git a/content/client-server-api/modules/room_previews.md b/content/client-server-api/modules/room_previews.md index f3368067..ecaedcbd 100644 --- a/content/client-server-api/modules/room_previews.md +++ b/content/client-server-api/modules/room_previews.md @@ -25,7 +25,7 @@ Clients can of course also call other endpoints such as [GET and [GET /search](#post_matrixclientr0search) to access events outside the `/events` stream. -{{peeking\_events\_cs\_http\_api}} +{{% http-api spec="client-server" api="peeking_events" %}} #### Server behaviour diff --git a/content/client-server-api/modules/room_upgrades.md b/content/client-server-api/modules/room_upgrades.md index 1e5437f3..08738d0a 100644 --- a/content/client-server-api/modules/room_upgrades.md +++ b/content/client-server-api/modules/room_upgrades.md @@ -24,7 +24,7 @@ old room. Another approach may be to virtually merge the rooms such that the old room's timeline seamlessly continues into the new timeline without the user having to jump between the rooms. -{{room\_upgrades\_cs\_http\_api}} +{{% http-api spec="client-server" api="room_upgrades" %}} #### Server behaviour diff --git a/content/client-server-api/modules/search.md b/content/client-server-api/modules/search.md index 3dfe6463..2fa5bc44 100644 --- a/content/client-server-api/modules/search.md +++ b/content/client-server-api/modules/search.md @@ -15,7 +15,7 @@ it won't include events in rooms that happened after you left. There is a single HTTP API for performing server-side search, documented below. -{{search\_cs\_http\_api}} +{{% http-api spec="client-server" api="search" %}} #### Search Categories diff --git a/content/client-server-api/modules/send_to_device.md b/content/client-server-api/modules/send_to_device.md index 5a879637..c1778863 100644 --- a/content/client-server-api/modules/send_to_device.md +++ b/content/client-server-api/modules/send_to_device.md @@ -52,7 +52,7 @@ should be sent on to the remote servers via #### Protocol definitions -{{to\_device\_cs\_http\_api}} +{{% http-api spec="client-server" api="to_device" %}} ##### Extensions to /sync diff --git a/content/client-server-api/modules/sso_login.md b/content/client-server-api/modules/sso_login.md index 36615375..18654b49 100644 --- a/content/client-server-api/modules/sso_login.md +++ b/content/client-server-api/modules/sso_login.md @@ -104,7 +104,7 @@ The client starts the process by instructing the browser to navigate to authentication is successful, the browser will be redirected to that `redirectUrl`. -{{sso\_login\_redirect\_cs\_http\_api}} +{{% http-api spec="client-server" api="sso_login_redirect" %}} ###### Security considerations diff --git a/content/client-server-api/modules/tags.md b/content/client-server-api/modules/tags.md index 94d455d2..28a74c9b 100644 --- a/content/client-server-api/modules/tags.md +++ b/content/client-server-api/modules/tags.md @@ -63,4 +63,4 @@ tags are defined in the `m.*` namespace: #### Client Behaviour -{{tags\_cs\_http\_api}} +{{% http-api spec="client-server" api="tags" %}} diff --git a/content/client-server-api/modules/third_party_invites.md b/content/client-server-api/modules/third_party_invites.md index 3b37dd97..45c94a93 100644 --- a/content/client-server-api/modules/third_party_invites.md +++ b/content/client-server-api/modules/third_party_invites.md @@ -37,7 +37,7 @@ invitee does indeed own that third party identifier. See the A client asks a server to invite a user by their third party identifier. -{{third\_party\_membership\_cs\_http\_api}} +{{% http-api spec="client-server" api="third_party_membership" %}} #### Server behaviour diff --git a/content/client-server-api/modules/third_party_networks.md b/content/client-server-api/modules/third_party_networks.md index 13142470..40ca1883 100644 --- a/content/client-server-api/modules/third_party_networks.md +++ b/content/client-server-api/modules/third_party_networks.md @@ -19,4 +19,4 @@ A client may wish to provide a rich interface for joining third party locations and connecting with third party users. Information necessary for such an interface is provided by third party lookups. -{{third\_party\_lookup\_cs\_http\_api}} +{{% http-api spec="client-server" api="third_party_lookup" %}} diff --git a/content/client-server-api/modules/typing_notifications.md b/content/client-server-api/modules/typing_notifications.md index d899b4e1..12417a64 100644 --- a/content/client-server-api/modules/typing_notifications.md +++ b/content/client-server-api/modules/typing_notifications.md @@ -33,7 +33,7 @@ recommended. When the user stops typing, the state change of the `boolean` to `false` should trigger another HTTP request to inform the server that the user has stopped typing. -{{typing\_cs\_http\_api}} +{{% http-api spec="client-server" api="typing" %}} #### Security considerations diff --git a/content/client-server-api/modules/voip_events.md b/content/client-server-api/modules/voip_events.md index 31cd3fec..b8b94df2 100644 --- a/content/client-server-api/modules/voip_events.md +++ b/content/client-server-api/modules/voip_events.md @@ -82,7 +82,7 @@ The homeserver MAY provide a TURN server which clients can use to contact the remote party. The following HTTP API endpoints will be used by clients in order to get information about the TURN server. -{{voip\_cs\_http\_api}} +{{% http-api spec="client-server" api="voip" %}} #### Security considerations diff --git a/content/identity-service-api.md b/content/identity-service-api.md index ef9d1bf0..3ce8b6fe 100644 --- a/content/identity-service-api.md +++ b/content/identity-service-api.md @@ -172,7 +172,7 @@ header is inaccessible for the client. When credentials are required but missing or invalid, the HTTP call will return with a status of 401 and the error code `M_UNAUTHORIZED`. -{{v2\_auth\_is\_http\_api}} +{{% http-api spec="identity" api="v2_auth" %}} ## Terms of service @@ -198,13 +198,13 @@ has just accepted are appended to `m.accepted_terms`. {{m\_accepted\_terms\_event}} -{{v2\_terms\_is\_http\_api}} +{{% http-api spec="identity" api="v2_terms" %}} ## Status check -{{ping\_is\_http\_api}} +{{% http-api spec="identity" api="ping" %}} -{{v2\_ping\_is\_http\_api}} +{{% http-api spec="identity" api="v2_ping" %}} ## Key management @@ -217,15 +217,15 @@ The identity server may also keep track of some short-term public-private keypairs, which may have different usage and lifetime characteristics than the service's long-term keys. -{{pubkey\_is\_http\_api}} +{{% http-api spec="identity" api="pubkey" %}} -{{v2\_pubkey\_is\_http\_api}} +{{% http-api spec="identity" api="v2_pubkey" %}} ## Association lookup -{{lookup\_is\_http\_api}} +{{% http-api spec="identity" api="lookup" %}} -{{v2\_lookup\_is\_http\_api}} +{{% http-api spec="identity" api="v2_lookup" %}} ### Client behaviour @@ -398,21 +398,21 @@ through without modification. ### Email associations -{{email\_associations\_is\_http\_api}} +{{% http-api spec="identity" api="email_associations" %}} -{{v2\_email\_associations\_is\_http\_api}} +{{% http-api spec="identity" api="v2_email_associations" %}} ### Phone number associations -{{phone\_associations\_is\_http\_api}} +{{% http-api spec="identity" api="phone_associations" %}} -{{v2\_phone\_associations\_is\_http\_api}} +{{% http-api spec="identity" api="v2_phone_associations" %}} ### General -{{associations\_is\_http\_api}} +{{% http-api spec="identity" api="associations" %}} -{{v2\_associations\_is\_http\_api}} +{{% http-api spec="identity" api="v2_associations" %}} ## Invitation storage @@ -427,9 +427,9 @@ the Matrix user's homeserver via the endpoint. The request MUST be signed with a long-term private key for the identity server. -{{store\_invite\_is\_http\_api}} +{{% http-api spec="identity" api="store_invite" %}} -{{v2\_store\_invite\_is\_http\_api}} +{{% http-api spec="identity" api="v2_store_invite" %}} ## Ephemeral invitation signing @@ -438,6 +438,6 @@ identity server offers some crypto functionality to help in accepting invitations. This is less secure than the client doing it itself, but may be useful where this isn't possible. -{{invitation\_signing\_is\_http\_api}} +{{% http-api spec="identity" api="invitation_signing" %}} -{{v2\_invitation\_signing\_is\_http\_api}} +{{% http-api spec="identity" api="v2_invitation_signing" %}} diff --git a/content/push-gateway-api.md b/content/push-gateway-api.md index a6a3d1a3..541db129 100644 --- a/content/push-gateway-api.md +++ b/content/push-gateway-api.md @@ -54,4 +54,4 @@ Note that most of the values and behaviour of this endpoint is described by the Client-Server API's [Push Module](/client-server-api#push-notifications). -{{push\_notifier\_push\_http\_api}} +{{% http-api spec="push-gateway" api="push_notifier" %}} diff --git a/content/server-server-api.md b/content/server-server-api.md index 21d6b495..beb175dd 100644 --- a/content/server-server-api.md +++ b/content/server-server-api.md @@ -150,11 +150,11 @@ SNI is not supported and should not be sent. Servers are encouraged to make use of the [Certificate Transparency](https://www.certificate-transparency.org/) project. -{{wellknown\_ss\_http\_api}} +{{% http-api spec="server-server" api="wellknown" %}} ### Server implementation -{{version\_ss\_http\_api}} +{{% http-api spec="server-server" api="version" %}} ### Retrieving server keys @@ -190,7 +190,7 @@ Homeservers publish their signing keys in a JSON object at homeserver and for signing events. It contains a list of `old_verify_keys` which are only valid for signing events. -{{keys\_server\_ss\_http\_api}} +{{% http-api spec="server-server" api="keys_server" %}} #### Querying Keys Through Another Server @@ -205,7 +205,7 @@ Notary servers can return keys for servers that are offline or having issues serving their own keys by using cached responses. Keys can be queried from multiple servers to mitigate against DNS spoofing. -{{keys\_query\_ss\_http\_api}} +{{% http-api spec="server-server" api="keys_query" %}} ## Authentication @@ -308,7 +308,7 @@ pair of homeservers that exchanged it; they are not globally-meaningful. Transactions are limited in size; they can have at most 50 PDUs and 100 EDUs. -{{transactions\_ss\_http\_api}} +{{% http-api spec="server-server" api="transactions" %}} ## PDUs @@ -559,7 +559,7 @@ to check with other servers to ensure it is receiving the correct auth chain. These APIs give the homeserver an avenue for getting the information it needs. -{{event\_auth\_ss\_http\_api}} +{{% http-api spec="server-server" api="event_auth" %}} ## EDUs @@ -623,7 +623,7 @@ Similar to backfilling a room's history, a server may not have all the events in the graph. That server may use the `/get_missing_events` API to acquire the events it is missing. -{{backfill\_ss\_http\_api}} +{{% http-api spec="server-server" api="backfill" %}} ## Retrieving events @@ -632,7 +632,7 @@ information about the room which cannot be easily determined from backfilling. These APIs provide homeservers with the option of getting events and the state of the room at a given point in the timeline. -{{events\_ss\_http\_api}} +{{% http-api spec="server-server" api="events" %}} ## Joining Rooms @@ -716,9 +716,9 @@ graph, and responds to the joining server with the full set of state for the newly-joined room. The resident server must also send the event to other servers participating in the room. -{{joins\_v1\_ss\_http\_api}} +{{% http-api spec="server-server" api="joins-v1" %}} -{{joins\_v2\_ss\_http\_api}} +{{% http-api spec="server-server" api="joins-v2" %}} ## Inviting to a room @@ -728,9 +728,9 @@ the process defined here. However, when a user invites another user on a different homeserver, a request to that homeserver to have the event signed and verified must be made. -{{invites\_v1\_ss\_http\_api}} +{{% http-api spec="server-server" api="invites-v1" %}} -{{invites\_v2\_ss\_http\_api}} +{{% http-api spec="server-server" api="invites-v2" %}} ## Leaving Rooms (Rejecting Invites) @@ -751,9 +751,9 @@ and replaces the `event_id` with its own. This is then sent to the resident server via `/send_leave`. The resident server will then send the event to other servers in the room. -{{leaving\_v1\_ss\_http\_api}} +{{% http-api spec="server-server" api="leaving-v1" %}} -{{leaving\_v2\_ss\_http\_api}} +{{% http-api spec="server-server" api="leaving-v2" %}} ## Third-party invites @@ -806,7 +806,7 @@ auth the event and send it. However, if the invited homeserver isn't in the room the invite came from, it will need to request the room's homeserver to auth the event. -{{third\_party\_invite\_ss\_http\_api}} +{{% http-api spec="server-server" api="third_party_invite" %}} #### Verifying the invite @@ -841,7 +841,7 @@ homeservers need a way to query the public rooms for another server. This can be done by making a request to the `/publicRooms` endpoint for the server the room directory should be retrieved for. -{{public\_rooms\_ss\_http\_api}} +{{% http-api spec="server-server" api="public_rooms" %}} ## Typing Notifications @@ -885,7 +885,7 @@ There are several types of queries that can be made. The generic endpoint to represent all queries is described first, followed by the more specific queries that can be made. -{{query\_ss\_http\_api}} +{{% http-api spec="server-server" api="query" %}} ## OpenID @@ -897,7 +897,7 @@ without granting full access to the user's account. Access tokens generated by the OpenID API are only good for the OpenID API and nothing else. -{{openid\_ss\_http\_api}} +{{% http-api spec="server-server" api="openid" %}} ## Device Management @@ -943,7 +943,7 @@ recognise, it must resynchronise its list by calling the `stream_id` which should be used to correlate with subsequent `m.device_list_update` EDUs. -{{user\_devices\_ss\_http\_api}} +{{% http-api spec="server-server" api="user_devices" %}} {{definition\_ss\_event\_schemas\_m\_device\_list\_update}} @@ -958,7 +958,7 @@ The APIs defined here are designed to be able to proxy much of the client's request through to federation, and have the response also be proxied through to the client. -{{user\_keys\_ss\_http\_api}} +{{% http-api spec="server-server" api="user_keys" %}} {{definition\_ss\_event\_schemas\_m\_signing\_key\_update}}