Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-01-03 14:38:37 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

spell out stream_id and fix todo

Browse source
This commit is contained in:
Matthew Hodgson 2018-09-01 02:10:45 +01:00
parent d377bedd76
commit 0afdcc59ea
2 changed files with 8 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
api/server-server/user_devices.yaml
View file

@ -57,10 +57,11 @@ paths:
stream_id:
type: integer
description: |-
An ID the requesting homeserver may use to detect changes in the
device list. This should increase as time goes on, and always
produce the same ``devices`` list if not incremented.
example: 334608
A unique ID for a given user_id which describes the version of
the returned device list. This is matched with the ``stream_id``
field in ``m.device_list_update`` EDUs in order to incrementally
update the returned device_list.
example: 5
devices:
type: array
description: The user's devices. May be empty.

8
specification/server_server_api.rst
View file

@ -1025,12 +1025,10 @@ This forms a simple directed acyclic graph of ``m.device_list_update`` EDUs, sho
which EDUs a server needs to have received in order to apply an update to its local
copy of the remote user's device list. If a server receives an EDU which refers to
a ``prev_id`` it does not recognise, it must resynchronise its list by calling the
/user/keys/query API and resume the process.
/user/keys/query API and resume the process. The response contains a ``stream_id``
which should be used to correlate with subsequent ``m.device_list_update`` EDUs.
..TODO: how do you synchronise the result of the /query API with the stream_id
in the EDUs?
..TODO: this whole thing desperately feels like it should just be state in a room,
.. TODO: this whole thing desperately feels like it should just be state in a room,
rather than inventing a whole different DAG. The same room could be used for
profiles, presence lists, etc.