|
|
@ -485,15 +485,6 @@ The destination name will be set to that of the receiving server itself. Each
|
|
|
|
embedded PDU in the transaction body will be processed.
|
|
|
|
embedded PDU in the transaction body will be processed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To fetch a particular PDU::
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GET .../pdu/<origin>/<pdu_id>/
|
|
|
|
|
|
|
|
Response: JSON encoding of a single Transaction containing one PDU
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Retrieves a given PDU from the server. The response will contain a single new
|
|
|
|
|
|
|
|
Transaction, inside which will be the requested PDU.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To fetch all the state of a given room::
|
|
|
|
To fetch all the state of a given room::
|
|
|
|
|
|
|
|
|
|
|
|
GET .../state/<room_id>/
|
|
|
|
GET .../state/<room_id>/
|
|
|
@ -503,6 +494,17 @@ Retrieves a snapshot of the entire current state of the given room. The
|
|
|
|
response will contain a single Transaction, inside which will be a list of PDUs
|
|
|
|
response will contain a single Transaction, inside which will be a list of PDUs
|
|
|
|
that encode the state.
|
|
|
|
that encode the state.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To fetch a particular event::
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GET .../event/<event_id>/
|
|
|
|
|
|
|
|
Response: JSON encoding of a partial Transaction containing the event
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Retrieves a single event. The response will contain a partial Transaction,
|
|
|
|
|
|
|
|
having just the ``origin``, ``origin_server_ts`` and ``pdus`` fields; the
|
|
|
|
|
|
|
|
event will be encoded as the only PDU in the ``pdus`` list.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To backfill events on a given room::
|
|
|
|
To backfill events on a given room::
|
|
|
|
|
|
|
|
|
|
|
|
GET .../backfill/<room_id>/
|
|
|
|
GET .../backfill/<room_id>/
|
|
|
@ -512,7 +514,6 @@ To backfill events on a given room::
|
|
|
|
Retrieves a sliding-window history of previous PDUs that occurred on the given
|
|
|
|
Retrieves a sliding-window history of previous PDUs that occurred on the given
|
|
|
|
room. Starting from the PDU ID(s) given in the "v" argument, the PDUs that
|
|
|
|
room. Starting from the PDU ID(s) given in the "v" argument, the PDUs that
|
|
|
|
preceded it are retrieved, up to a total number given by the "limit" argument.
|
|
|
|
preceded it are retrieved, up to a total number given by the "limit" argument.
|
|
|
|
These are then returned in a new Transaction containing all of the PDUs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To stream events all the events::
|
|
|
|
To stream events all the events::
|
|
|
@ -690,11 +691,42 @@ following keys:
|
|
|
|
|
|
|
|
|
|
|
|
Backfilling
|
|
|
|
Backfilling
|
|
|
|
-----------
|
|
|
|
-----------
|
|
|
|
.. NOTE::
|
|
|
|
|
|
|
|
This section is a work in progress.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.. TODO-doc
|
|
|
|
Once a homeserver has joined a room, it receives all the events emitted by
|
|
|
|
- What it is, when is it used, how is it done
|
|
|
|
other homeservers in that room, and is thus aware of the entire history of the
|
|
|
|
|
|
|
|
room from that moment onwards. Since users in that room are able to request the
|
|
|
|
|
|
|
|
history by the ``/messages`` client API endpoint, it's possible that they might
|
|
|
|
|
|
|
|
step backwards far enough into history before the homeserver itself was a
|
|
|
|
|
|
|
|
member of that room.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To cover this case, the federation API provides a server-to-server analog of
|
|
|
|
|
|
|
|
the ``/messages`` client API, allowing one homeserver to fetch history from
|
|
|
|
|
|
|
|
another. This is the ``/backfill`` API.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To request more history, the requesting homeserver picks another homeserver
|
|
|
|
|
|
|
|
that it thinks may have more (most likely this should be a homeserver for some
|
|
|
|
|
|
|
|
of the existing users in the room at the earliest point in history it has
|
|
|
|
|
|
|
|
currently), and makes a ``/backfill`` request. The parameters of this request
|
|
|
|
|
|
|
|
give an event ID that the requesting homeserver wishes to obtain, and a number
|
|
|
|
|
|
|
|
specifying how many more events of history before that one to return at most.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The response to this request is an object with the following keys:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
==================== ======== ============
|
|
|
|
|
|
|
|
Key Type Description
|
|
|
|
|
|
|
|
==================== ======== ============
|
|
|
|
|
|
|
|
``pdus`` List A list of events
|
|
|
|
|
|
|
|
``origin`` String The name of the resident homeserver
|
|
|
|
|
|
|
|
``origin_server_ts`` Integer A timestamp added by the resident homeserver
|
|
|
|
|
|
|
|
==================== ======== ============
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The list of events given in ``pdus`` is returned in reverse chronological
|
|
|
|
|
|
|
|
order; having the most recent event first (i.e. the event whose event ID is
|
|
|
|
|
|
|
|
that requested by the requestor in the ``v`` parameter).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.. TODO-spec
|
|
|
|
|
|
|
|
Specify (or remark that it is unspecified) how the server handles divergent
|
|
|
|
|
|
|
|
history. DFS? BFS? Anything weirder?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Authentication
|
|
|
|
Authentication
|
|
|
|