wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Update content to call the new template for HTTP APIs

Browse source
This commit is contained in:
Will 2021-01-29 15:32:31 -08:00 • committed by Richard van der Hoff
parent 1d629bae40
commit 52f5e73a39
27 changed files with 98 additions and 98 deletions
Download patch file Download diff file Expand all files Collapse all files

10
content/application-service-api.md
View file

@ -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

56
content/client-server-api/_index.md
View file

@ -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/<room_id>/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

2
content/client-server-api/modules/account_data.md
View file

@ -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

2
content/client-server-api/modules/admin.md
View file

@ -10,4 +10,4 @@ server state and data.
#### Client Behaviour
{{admin\_cs\_http\_api}}
{{% http-api spec="client-server" api="admin" %}}

2
content/client-server-api/modules/content_repo.md
View file

@ -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

2
content/client-server-api/modules/device_management.md
View file

@ -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

6
content/client-server-api/modules/end_to_end_encryption.md
View file

@ -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

2
content/client-server-api/modules/event_context.md
View file

@ -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

2
content/client-server-api/modules/openid.md
View file

@ -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" %}}

2
content/client-server-api/modules/presence.md
View file

@ -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

6
content/client-server-api/modules/push.md
View file

@ -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

2
content/client-server-api/modules/read_markers.md
View file

@ -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

2
content/client-server-api/modules/receipts.md
View file

@ -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

2
content/client-server-api/modules/report_content.md
View file

@ -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

2
content/client-server-api/modules/room_previews.md
View file

@ -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

2
content/client-server-api/modules/room_upgrades.md
View file

@ -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

2
content/client-server-api/modules/search.md
View file

@ -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

2
content/client-server-api/modules/send_to_device.md
View file

@ -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

2
content/client-server-api/modules/sso_login.md
View file

@ -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

2
content/client-server-api/modules/tags.md
View file

@ -63,4 +63,4 @@ tags are defined in the `m.*` namespace:
#### Client Behaviour
{{tags\_cs\_http\_api}}
{{% http-api spec="client-server" api="tags" %}}

2
content/client-server-api/modules/third_party_invites.md
View file

@ -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

2
content/client-server-api/modules/third_party_networks.md
View file

@ -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" %}}

2
content/client-server-api/modules/typing_notifications.md
View file

@ -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

2
content/client-server-api/modules/voip_events.md
View file

@ -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

36
content/identity-service-api.md
View file

@ -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" %}}

2
content/push-gateway-api.md
View file

@ -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" %}}

40
content/server-server-api.md
View file

@ -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}}