The pos is a token which keeps track of where the client got in the sync stream for sliding sync. It's similar to the next-batch token concept from sync v2.
As such, it is useful to persist the pos between client restarts so the client may continue where they left off.
Since we have relatively complex multi-process situation on iOS, this value had to be stored in a cross-process safe manner.
As such we introduced a hack to persist the pos in the crypto store.
|
#[cfg(feature = "e2e-encryption")] |
|
{ |
|
let position = _position; |
|
let instance_storage_key = format_storage_key_for_sliding_sync(storage_key); |
|
|
|
// FIXME (TERRIBLE HACK): we want to save `pos` in a cross-process safe manner, |
|
// with both processes sharing the same database backend; that needs to |
|
// go in the crypto process store at the moment, but should be fixed |
|
// later on. |
|
if let Some(olm_machine) = &*sliding_sync.inner.client.olm_machine().await { |
|
let pos_blob = serde_json::to_vec(&FrozenSlidingSyncPos { pos: position.pos.clone() })?; |
|
olm_machine.store().set_custom_value(&instance_storage_key, pos_blob).await?; |
|
} |
|
} |
This works relatively well, but users which don't use the end-to-end encryption feature lose this functionality. We should find a new home for this value.
Since the event cache store is now cross-process compatible it seems like the best candidate.
The
posis a token which keeps track of where the client got in the sync stream for sliding sync. It's similar to thenext-batchtoken concept from sync v2.As such, it is useful to persist the
posbetween client restarts so the client may continue where they left off.Since we have relatively complex multi-process situation on iOS, this value had to be stored in a cross-process safe manner.
As such we introduced a hack to persist the
posin the crypto store.matrix-rust-sdk/crates/matrix-sdk/src/sliding_sync/cache.rs
Lines 56 to 69 in d039dad
This works relatively well, but users which don't use the end-to-end encryption feature lose this functionality. We should find a new home for this value.
Since the event cache store is now cross-process compatible it seems like the best candidate.