Benjamin Kampmann d3ff402813 feat(sliding-sync): Offline caching for Sliding Sync & session recovery (#1193)
With these changes, the user of sliding sync can configure the SlidingSync-Builder to store and recover the state from storage. For that they should call cold_cache("my-sliding-sync-key") with their preferred storage location during setup time on SlidingSyncBuilder. If a cached version is found under that key, the internal state of the rooms-list as well as each view found (identified by their name) will be set from storage immediately - allowing the user to show the last cached state. The Builder then also uses the same key to store its latest state after every update received from remote.

👉 Note on room list:
As we store a disconnected state, we are saving all RoomList entries as either Empty or Invalidated. This allows for an easier updating when the server comes back with results, as we don't track the ranges in cache - in the view of the server, we haven't seen anything yet.

👉 Note on timeline events:
This does store all existing timeline events - initial and seen during the session (as we keep track of them right now) - and will recover that state. However, as we can't be sure wether we have gaps in the timeline, the timeline items are reset upon receiving updates for them from the server.

👉 Note on (full-sync-)view:
While we are caching the server returned results (view list, room count and room info) as is, we are not caching the internal state (whether we are catching up) nor the ranges (as they are likely to be out of date) - those will be acting the same way you configured them, just with preloaded results. So for a full-sync-view, it will still do requests in batches and replace the corresponding set of rooms. Which could mean you might see the same room appear twice, though the cached one would be marked as invalidated. This might be problematic if the list the UI shows is longer than the batches fetched, but would be resolved quickly when catching up.

👉 On recovery:
When the sliding sync receives a M_UNKNOWN_POS, indicating the server has expired our session, sliding sync now transparently retries with up to three times to restart the sliding sync with full set of extensions and the latest views at their existing windows, the current room state is held. For full sync this starts a new sync-up with the existing room list staying intact. This also works from the offline at start.
2022-11-28 18:01:04 +00:00
2022-11-15 14:57:46 +01:00
2022-11-24 13:43:09 +01:00
2022-08-01 14:33:05 +02:00
2022-09-30 21:54:09 +02:00
2022-07-21 15:47:00 +02:00
2022-11-15 14:57:46 +01:00

Build Status codecov License #matrix-rust-sdk Docs - Main Docs - Stable

matrix-rust-sdk

matrix-rust-sdk is an implementation of a Matrix client-server library in Rust.

Project structure

The rust-sdk consists of multiple crates that can be picked at your convenience:

  • matrix-sdk - High level client library, with batteries included, you're most likely interested in this.
  • matrix-sdk-base - No (network) IO client state machine that can be used to embed a Matrix client in your project or build a full fledged network enabled client lib on top of it.
  • matrix-sdk-crypto - No (network) IO encryption state machine that can be used to add Matrix E2EE support to your client or client library.

Minimum Supported Rust Version (MSRV)

These crates are built with the Rust language version 2021 and require a minimum compiler version of 1.65.

Status

The library is in an alpha state, things that are implemented generally work but the API will change in breaking ways.

If you are interested in using the matrix-sdk now is the time to try it out and provide feedback.

Bindings

Some crates of the matrix-rust-sdk can be embedded inside other environments, like Swift, Kotlin, JavaScript, Node.js etc. Please, explore the bindings/ directory to learn more.

License

Apache-2.0

Description
No description provided
Readme 146 MiB
Languages
Rust 99.7%
HTML 0.2%