1f349/dendrite
4
0
Fork 0
mirror of https://github.com/1f349/dendrite.git synced 2024-11-22 11:41:38 +00:00
Code Issues Packages Projects Releases Wiki Activity

State of the union update

Browse Source
This commit is contained in:
Kegsay 2017-05-17 16:36:17 +01:00 committed by GitHub
parent ccd0eb2851
commit 0457a3bb69
1 changed files with 25 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
src/github.com/matrix-org/dendrite/syncapi/README.md
View File

@ -1,6 +1,13 @@
# Sync API Server
This server is responsible for servicing `/sync` requests. It gets its data from the room server output log.
This server is responsible for servicing `/sync` requests. It gets its data from the room server output log. Currently, the sync server will:
- Return a valid `/sync` response for the user represented by the provided `access_token`.
- Return a "complete sync" if no `since` value is provided, and return a valid `next_batch` token. This contains all rooms the user has been invited to or has joined. For joined rooms, this includes the complete current room state and the most recent 20 (hard-coded) events in the timeline.
- For "incremental syncs" (a `since` value is provided), as you get invited to, join, or leave rooms they will be reflected correctly in the `/sync` response.
- For very large state deltas, the `state` section of a room is correctly populated with the state of the room at the *start* of the timeline.
- When you join a room, the `/sync` which transitions your client to be "joined" will include the complete current room state as per the specification.
- Only wake up user streams it needs to wake up.
- Honours the `timeout` query parameter value.
## Internals
@ -59,3 +66,20 @@ are in `OutputRoomEvents` from the room server.
This version of the sync server uses very simple indexing to calculate room state at various points.
This is inefficient when a very old `since` value is provided, or the `full_state` is requested, as the state delta becomes
very large. This is mitigated slightly with indexes, but better data structures could be used in the future.
## Known Issues
- `m.room.history_visibility` is not honoured: it is always treated as "shared".
- All ephemeral events are not implemented (presence, typing, receipts).
- Account data (both user and room) is not implemented.
- `to_device` messages are not implemented.
- Back-pagination via `prev_batch` is not implemented.
- The `limited` flag can lie.
- Filters are not honoured or implemented. The `limit` for each room is hard-coded to 20.
- The `full_state` query parameter is not implemented.
- The `set_presence` query parameter is not implemented.
- "Ignored" users are not ignored.
- Redacted events are still sent to clients.
- Invites over federation (if it existed) won't work as they aren't "real" events and so won't be in the right tables.
- `invite_state` is not implemented (for similar reasons to the above point).
- The current implementation scales badly when a very old `since` token is provided.