[meta] Latest Event API, the missing one

[Hywan]

David (Bernini)

---

The Latest Event represents the event that is displayed in the Room List under each room item, or displayed as a Thread Summary. It is important, and must be reactive. It follows several constraints, such as:

• Not all events are a candidate to be a Latest Event, e.g. state events aren't candidate; thus the Latest Event has to paginate through events in reverse order (from newest to oldest) to find a suitable event if any, otherwise the information that no candidate has been found must be present,
• It must represent remote and local events for a better user experience.

The Latest Event API in its current form was added a bit in an ad-hoc way, since we needed the feature but lacked the proper storage layer for events, and the proper send queue. What we can re-use though is all the logic to find a suitable event, which was not trivial to write in an efficient way knowing we have to deal with encrypted event and so on.

Today is different: We have the Event Cache API, and we have the Send Queue API. Those are the two components we need to write a proper Latest Event API! I love it when a plan comes together.

The Latest Event API in its current form is scattered in multiple crates. It's going to be hard to “migrate”, or move things together. The plan we came up with the team is to write a new API from scratch, and then migrate the components using a Latest Event one by one.

Important

Storage

A note about the storage. The Event Cache API has its own storage. The Send Queue API has its own storage. The Latest Event API will be computation only, no storage is required, and that will solve multiple problems. Right now, the Latest Event is stored in RoomInfo, which is not a good place.

Important

Thread

Another note about threads. The Latest Event API in its current form is only used by the Rooms. But we need it to work with Threads too, as it is required for Thread Summary.

Plan

Create the Latest Event API

• Create the Latest Event API
  • The entry point is matrix_sdk::latest_events::LatestEvents
  • LatestEvents is lazy, it computes and keeps only requested LatestEvents in memory
  • Provide a LatestEvent type
  • Provide a LatestEventSubscriber type
    • It implements Stream<Item = LatestEvent>
    • ❓ It implements an “auto-drop” mechanism: when there is no more listener for all clones of the same LatestEventSubscriber, lets' drop it from LatestEvents
  • LatestEvents listens to the Event Cache for remote events
    • Provide a LatestEvents::subscribe_to_room(&self, &RoomId) -> (Option<LatestEvent>, LatestEventSubscriber) (note: Option<LatestEvent> to handle the case where there is no suitable LatestEvent)
    • Provide a LatestEvents::subscribe_to_thread(&self, &RoomId, &EventId) -> (Option<LatestEvent>, LatestEventSubscriber)
    • LatestEvents uses the Event Cache to find a suitable event
      • Be able to back-paginate in the storage
      • Be able to back-paginate in the network
  • LatestEvents listens to the Send Queue for local events
    • Send Queue has a higher priority than Event Cache, i.e. if there is a local event, it must always be used for the LatestEvent

Use the Latest Event API

• Use the Latest Event API
  • matrix_sdk_ui::room_list_service uses LatestEvents
    • room_list_service::Room::latest_event() uses LatestEvents to retrieve a single LatestEvent
      • This method no longer needs a Timeline to fetch the LatestEvent!
    • room_list_service::RoomList::entries_with_dynamic_adapter() should not need any modification (see next section)

Notify matrix_sdk::Room when the LatestEvent changes

• Notify a matrix_sdk::Room when the LatestEvent changes
  • Rename RoomInfoNotableUpdate to RoomNotableUpdate
  • Rename RoomInfoNotableUpdateReasons to RoomNotableUpdateReasons
  • LatestEvents is able to send a RoomNotableUpdate by itself, with the reason RoomNotableUpdateReasons::LATEST_EVENT

Clean up

• Clean up
  • Remove the old LatestEvent API wherever it lives

Re-decryption

• Re-decryption
  • An encrypted event is decrypted during the sync flow. Sometimes, it's not possible to decrypt an encrypted event because not all information are present. In this case, we need to re-decrypt it later. The re-decryption logic current lives in the matrix_sdk_ui::timeline, but it should move inside the Event Cache soon. How it will interact with the Latest Event API is still unclear but ultimately should be transparent (the RoomEventCache stream of updates should notify that a new event has been updated, and the machine should handle that seamlessly).

[bnjbvr]

Dup of #4112.