[Story] 🦀 Event cache storage

[manuroe]

Description

• As a user
• I do not want the app to reload timeline content every time
• So that I enjoy a snappy app with timeline instantly displayed

This project is about to make the existing Event Cache API persistent. The event cache exists but it is a in-memory cache. We want it to be a on-disk cache.

Acceptance criteria

• Live timeline events are permanently cached
• This cache is reset in case of a gap in the timeline
• The room list pre-fills this cache with X last messages so that the timeline instantly displays when the user opens a room
• More to be discussed

Leads

• Tech: @Hywan
• Design:

Size estimate

None

Dependencies

• None

Out of scope

• Preload the cache from the notification service

Open questions

### Questions

Subtasks

### Android

### iOS

### Rust
- [ ] https://github.com/matrix-org/matrix-rust-sdk/issues/3280

### Other

Sign-off

Android

• Design sign-off on completion
• QA sign-off on completion
• Product sign-off on completion

iOS

• Design sign-off on completion
• QA sign-off on completion
• Product sign-off on completion

[Hywan]

This cache is reset in case of a gap in the timeline

Why? We get gaps pretty often, what's the goal of this feature?

The room list pre-fills this cache with X last messages so that the timeline instantly displays when the user opens a room

It has nothing to do with the event cache storage right? It's a sync requirement (which is already present).

[Hywan]

The full issue that describes all the work is matrix-org/matrix-rust-sdk#3280.

[manuroe]

@Hywan we need to discuss this user story and the acceptance criteria when we will be on it. This issue is even not a user story more a tech stories. The Event Cache Storage work can probably be splitted into several user stories.

This cache is reset in case of a gap in the timeline

Why? We get gaps pretty often, what's the goal of this feature?

I would be happy to remove this acceptance criteria. The occurence of the reset depends on the rooms traffic. Legacy SDKs reset the timeline DB in this case.
We tried in the android SDK to keep multiple chunks of continous timelime items in the DB. When 2 chunks intersected, we merged them together into a big one but it required too much effort to get it right. Instead, we now keep only one in EA, the "live" chunk.

It appeared it was enough in term of UX in legacy apps. Thanks to notifications that regularly make v2 /sync requests, there are not that much timeline gap in useful, not too active, rooms. It is going to be different with SSS.

The room list pre-fills this cache with X last messages so that the timeline instantly displays when the user opens a room

It has nothing to do with the event cache storage right? It's a sync requirement (which is already present).

We still have the problem in EX that if all the messages returned by the default sync limit are not displayable, there is no last message in the room list. Legacy apps run /messages in those rooms to find a displayable last message.

[Hywan]

This cache is reest in case of a gap in the timeline.

Why? We get gaps pretty often, what's the goal of this feature?

I would be happy to remove this acceptance criteria. The occurence of the reset depends on the rooms traffic. Legacy SDKs reset the timeline DB in this case.

Right now, the event cache lives in memory, and it handles gaps pretty well. The persistent storage will just be a replica of what we have in memory, nothing fancy will be done here, just a 1:1 mapping.

We also want to use the event cache persistent storage to be able to provide search (text, media…). If we reset the storage frequently, we fail to provide these cool features.

[manuroe]

The associated epic is closed. The rust meta issue where the work happened is closed. We can close this intermediate one.