- Move svg / bandwidth code to devtools.js
- Move HTTP API code to SlidingSyncConnection (with abort controller and tx/rx stats)
- Remove debug commands: they need to be re-done to be actually useful for developers.
Using ANY allows us to give a single parameter containing many many
entries, which bypasses the postgres parameter limit of 65535. Without
this, large rooms like Matrix HQ which have current state >65535 events
will not be stored correctly.
Add torture test to the events table to assert that we can query >65535
events.
- Persist OTK counts and device list changes in-memory per Poller.
- Expose a new `E2EEFetcher` to allow the E2EE extension code to
grab said E2EE data from the Poller.
- OTK counts are replaced outright.
- Device lists are updated in a user_id->changed|left map which is then
deleted when read.
- Add tests for basic functionality and some edge cases like ensuring that
v3 request retries still return changed|left values.
Extensions will be the main way to compartmentalise additional
/sync functionality beyond the baseline of a sliding window
and room subscriptions. Things like presence, to-device messages,
receipts, OTK counts and device lists, typing, etc can all live
as optional opt-in extensions to the core protocol.
The intention is that extensions can lean on the baseline
functionality to get information like "which rooms are present
in the sliding window" and "which rooms are directly subscribed to"
in order to aid their calculations. For example, a typing extension
may have a flag to only show typing notifications in directly
subscribed rooms (e.g rooms whose timelines are visible). To-device
extensions by comparison will just be a simple 'fetch more events'
API as it cannot make use of visible rooms in any meaningful way
as metadata is encrypted, but will make use of an explicit `since`
token to avoid implicit ACKs which plague sync v2. Presence extensions
may only load presence status for users who are joined to the
sliding window of rooms rather than all rooms. This functionality
can be provided without bogging down the logic with sliding window
handling.
This means we can serve rooms/events from the v3 database
immediately if they exist. The downside is that we still do
need to hit v2 to pull in to-device messages, but they can
come in later.
We cache timelines in-memory per-room. If the initial timeline
request was small, and then a larger timeline limit was used
(say in a room subscription) then we would not fetch more events.
We now invalidate the cache if we don't have enough events AND
there is no create event in the timeline (indicating there should
be more).
