|
|
|
@ -150,11 +150,11 @@ SNI is not supported and should not be sent.
|
|
|
|
Servers are encouraged to make use of the [Certificate
|
|
|
|
Servers are encouraged to make use of the [Certificate
|
|
|
|
Transparency](https://www.certificate-transparency.org/) project.
|
|
|
|
Transparency](https://www.certificate-transparency.org/) project.
|
|
|
|
|
|
|
|
|
|
|
|
{{wellknown\_ss\_http\_api}}
|
|
|
|
{{% http-api spec="server-server" api="wellknown" %}}
|
|
|
|
|
|
|
|
|
|
|
|
### Server implementation
|
|
|
|
### Server implementation
|
|
|
|
|
|
|
|
|
|
|
|
{{version\_ss\_http\_api}}
|
|
|
|
{{% http-api spec="server-server" api="version" %}}
|
|
|
|
|
|
|
|
|
|
|
|
### Retrieving server keys
|
|
|
|
### 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
|
|
|
|
homeserver and for signing events. It contains a list of
|
|
|
|
`old_verify_keys` which are only valid for signing events.
|
|
|
|
`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
|
|
|
|
#### 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
|
|
|
|
issues serving their own keys by using cached responses. Keys can be
|
|
|
|
queried from multiple servers to mitigate against DNS spoofing.
|
|
|
|
queried from multiple servers to mitigate against DNS spoofing.
|
|
|
|
|
|
|
|
|
|
|
|
{{keys\_query\_ss\_http\_api}}
|
|
|
|
{{% http-api spec="server-server" api="keys_query" %}}
|
|
|
|
|
|
|
|
|
|
|
|
## Authentication
|
|
|
|
## 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
|
|
|
|
Transactions are limited in size; they can have at most 50 PDUs and 100
|
|
|
|
EDUs.
|
|
|
|
EDUs.
|
|
|
|
|
|
|
|
|
|
|
|
{{transactions\_ss\_http\_api}}
|
|
|
|
{{% http-api spec="server-server" api="transactions" %}}
|
|
|
|
|
|
|
|
|
|
|
|
## PDUs
|
|
|
|
## 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
|
|
|
|
chain. These APIs give the homeserver an avenue for getting the
|
|
|
|
information it needs.
|
|
|
|
information it needs.
|
|
|
|
|
|
|
|
|
|
|
|
{{event\_auth\_ss\_http\_api}}
|
|
|
|
{{% http-api spec="server-server" api="event_auth" %}}
|
|
|
|
|
|
|
|
|
|
|
|
## EDUs
|
|
|
|
## 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
|
|
|
|
events in the graph. That server may use the `/get_missing_events` API
|
|
|
|
to acquire the events it is missing.
|
|
|
|
to acquire the events it is missing.
|
|
|
|
|
|
|
|
|
|
|
|
{{backfill\_ss\_http\_api}}
|
|
|
|
{{% http-api spec="server-server" api="backfill" %}}
|
|
|
|
|
|
|
|
|
|
|
|
## Retrieving events
|
|
|
|
## 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
|
|
|
|
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 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
|
|
|
|
## 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
|
|
|
|
the newly-joined room. The resident server must also send the event to
|
|
|
|
other servers participating in the room.
|
|
|
|
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
|
|
|
|
## 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
|
|
|
|
different homeserver, a request to that homeserver to have the event
|
|
|
|
signed and verified must be made.
|
|
|
|
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)
|
|
|
|
## 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
|
|
|
|
resident server via `/send_leave`. The resident server will then send
|
|
|
|
the event to other servers in the room.
|
|
|
|
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
|
|
|
|
## 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
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
#### 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
|
|
|
|
This can be done by making a request to the `/publicRooms` endpoint for
|
|
|
|
the server the room directory should be retrieved 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
|
|
|
|
## 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
|
|
|
|
endpoint to represent all queries is described first, followed by the
|
|
|
|
more specific queries that can be made.
|
|
|
|
more specific queries that can be made.
|
|
|
|
|
|
|
|
|
|
|
|
{{query\_ss\_http\_api}}
|
|
|
|
{{% http-api spec="server-server" api="query" %}}
|
|
|
|
|
|
|
|
|
|
|
|
## OpenID
|
|
|
|
## 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
|
|
|
|
Access tokens generated by the OpenID API are only good for the OpenID
|
|
|
|
API and nothing else.
|
|
|
|
API and nothing else.
|
|
|
|
|
|
|
|
|
|
|
|
{{openid\_ss\_http\_api}}
|
|
|
|
{{% http-api spec="server-server" api="openid" %}}
|
|
|
|
|
|
|
|
|
|
|
|
## Device Management
|
|
|
|
## 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
|
|
|
|
`stream_id` which should be used to correlate with subsequent
|
|
|
|
`m.device_list_update` EDUs.
|
|
|
|
`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}}
|
|
|
|
{{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
|
|
|
|
client's request through to federation, and have the response also be
|
|
|
|
proxied through to the client.
|
|
|
|
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}}
|
|
|
|
{{definition\_ss\_event\_schemas\_m\_signing\_key\_update}}
|
|
|
|
|
|
|
|
|
|
|
|
|
Will
4 years ago
committed by