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

Decorate the rest of the appservice login stuff too

Browse source
This commit is contained in:
Travis Ralston 2021-12-28 14:23:23 -07:00
parent 76aaf39811
commit afb6867232
1 changed files with 8 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -1024,8 +1024,10 @@ is complete, the client will need to submit a `/login` request matching
#### Appservice Login #### Appservice Login
{{% added-in v="1.2" %}}
An appservice can log in by providing a valid appservice token and a user within the appservice's An appservice can log in by providing a valid appservice token and a user within the appservice's
namespace. namespace.
{{% boxes/note %}} {{% boxes/note %}}
Appservices do not need to log in as individual users in all cases, as they Appservices do not need to log in as individual users in all cases, as they
@ -1034,7 +1036,7 @@ using the appservice token. However, if the appservice needs a scoped token
for a single user then they can use this API instead. for a single user then they can use this API instead.
{{% /boxes/note %}} {{% /boxes/note %}}
This request must be authenticated by the [appservice `as_token`](/application-service-api#registration) This request must be authenticated by the [appservice `as_token`](/application-service-api#registration)
(see [Client Authentication](#client-authentication) on how to provide the token). (see [Client Authentication](#client-authentication) on how to provide the token).
To use this login type, clients should submit a `/login` request as follows: To use this login type, clients should submit a `/login` request as follows:
@ -1499,7 +1501,7 @@ of the message timeline. The client can fill these gaps using the
[`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientv3roomsroomidmessages) API. [`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientv3roomsroomidmessages) API.
Continuing our example, suppose we make a third `/sync` request asking for Continuing our example, suppose we make a third `/sync` request asking for
events since the last sync, by passing the `next_batch` token `x-y-z` as events since the last sync, by passing the `next_batch` token `x-y-z` as
the `since` parameter. The server knows about four new events, `E7`, `E8`, the `since` parameter. The server knows about four new events, `E7`, `E8`,
`E9` and `E10`, but decides this is too many to report at once. Instead, `E9` and `E10`, but decides this is too many to report at once. Instead,
the server sends a `limited` response containing `E8`, `E9` and `E10`but the server sends a `limited` response containing `E8`, `E9` and `E10`but
@ -1511,14 +1513,14 @@ omitting `E7`. This forms a gap, which we can see in the visualisation:
[E0]->[E1]->[E2]->[E3]->[E4]->[E5]->[E6]->[E7]->[E8]->[E9]->[E10] [E0]->[E1]->[E2]->[E3]->[E4]->[E5]->[E6]->[E7]->[E8]->[E9]->[E10]
^ ^ ^ ^ ^ ^
| | | | | |
since: 'x-y-z' | | since: 'x-y-z' | |
prev_batch: 'd-e-f' next_batch: 'u-v-w' prev_batch: 'd-e-f' next_batch: 'u-v-w'
``` ```
The limited response includes a state delta which describes how the state The limited response includes a state delta which describes how the state
of the room changes over the gap. This delta explains how to build the state of the room changes over the gap. This delta explains how to build the state
prior to returned timeline (i.e. at `E7`) from the state the client knows prior to returned timeline (i.e. at `E7`) from the state the client knows
(i.e. at `E6`). To close the gap, the client should make a request to (i.e. at `E6`). To close the gap, the client should make a request to
[`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientv3roomsroomidmessages) [`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientv3roomsroomidmessages)
with the query parameters `from=x-y-z` and `to=d-e-f`. with the query parameters `from=x-y-z` and `to=d-e-f`.