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

Initial Sync: Ongoing > Draft with additional work

Browse source 
Descoped some points to v2.1 as discussed irl.
This commit is contained in:
Kegsay 2015-01-12 15:52:19 +00:00
parent 8fc472c13c
commit e2894045d5
1 changed files with 35 additions and 32 deletions
Download patch file Download diff file Expand all files Collapse all files

49
drafts/general_api.rst
View file

@ -9,33 +9,35 @@ Summary of changes from v1
Version 2.0
-----------
- Event filtering (type/room/users, federation-style events)
- Incremental initial syncing
- Deleting state
- Race conditions on event stream / actions
- Out-of-order events
- Published room API: support searching remote HSes.
- Account management: specifically the concept of devices so push works.
- Multiple devices
- Event filtering (type/room/users, federation-style events)
- Incremental initial syncing
- Deleting state
- Race conditions on event stream / actions
- Out-of-order events
- Published room API: support searching remote HSes.
- Account management: specifically the concept of devices so push works.
- Multiple devices
- Presence status unioning: is partially specced (needs more eyes).
- Syncing data between multiple devices: is specced.
- TODO: Push for offline devices.
Lower priority
~~~~~~~~~~~~~~
- Capabilities
- Editing/updating messages (updates key)
- Room alias API
- Capabilities
- Editing/updating messages (updates key)
- Room alias API
Version 2.1
-----------
- Comments (relates_to key)
- Contextual messages (view messages around an arbitrary message)
- Rejecting invites
- Comments (relates_to key)
- Contextual messages (view messages around an arbitrary message)
- Rejecting invites
- State event pagination (e.g. from initial sync)
- Initial sync pagination (e.g. X most recent rooms)
Out of scope
------------
- Searching messages
- Searching messages
Version 2 API
=============
@ -106,24 +108,21 @@ Notes:
allow APIs which use filtering to ALSO specifiy query parameters to tweak the
filter.
Global initial sync API ``[ONGOING]``
Global initial sync API ``[Draft]``
-------------------------------------
.. NOTE::
v2.1:
- Will need some form of state event pagination like we have for message events
to handle large amounts of state events for a room. Need to think of the
consequences of this: you may not get a ``m.room.member`` for someone's
message and so cannot display their display name / avatar. Do we want to
provide pagination on an event type basis?
- Handle paginating initial sync results themselves (e.g. 10 most recent rooms)
- No need for state events under the 'state' key to have a ``prev_content``.
Can also apply some optimisations depending on the direction of travel when
scrolling back.
- Do we want to treat global / specific room initial syncs as separate entities?
Aren't they just a filter?
Inputs:
- A way of identifying the user (e.g. access token, user ID, etc)
- Filter to apply
- Filter to apply (e.g. a single room ID for a 'room initial sync')
- Chunk token (for incremental deltas)
Outputs:
- For each room the user is joined:
@ -143,7 +142,11 @@ Compacting notes:
messages: [ event_id, event_id, ...],
state: [ event_id, event_id, ...],
}
Duplicate content notes:
- For non-compacted state events, duplicate state events in the ``messages`` key need to
have a ``prev_content`` to correctly display the state change text. This is not required
for ``state`` key events, which just represent the *current* state and as such do not
need a ``prev_content``. Compacted state events will need to specify the ``prev_content``.
What data flows does it address:
- Home screen: data required on load.