[Prep] Threads: Threads catchup mechanism

[manuroe]

Description

In the context of threads 2.0, we want a smart mechanism to update threads. We need such mecanisms for several reasons:

• update the unread status
• compute mention badge
• update the thread list in the activity center ( https://github.com/element-hq/element-meta/issues/2768)

We need SSS to provide threads updates in an efficient way.

Acceptance criteria

• TBD

Dependencies

• None

Out of scope

• EX could do like for threads 1.0 with /relations or back paginate the entire room to previous known event but we know it is not usable for the end users.
  • We expimented it but the performance does not make it usable

Subtasks

MSC

• https://github.com/matrix-org/matrix-spec-proposals/pull/4360

Synapse

• https://github.com/element-hq/synapse/issues/18436
• https://github.com/element-hq/synapse/pull/19041

Rust

• https://github.com/matrix-org/matrix-rust-sdk/issues/5039

Other

[manuroe]

@bnjbvr experimented catchup using /relations:

• this is too slow overall to try to grab the list of all the previous threads,
• this implies that we'll need some kind of pagination mechanism to get the list of threads in a room
• also this means we can't use this to rebuild the list of threads that have been updated;

--> so we do need an SSS extension to get this information.

[bnjbvr]

Thanks Manu, that's right; one thing to note down is that, in my experiment, I've tried to retrieve all the threads' latest events using /threads. If we limit that to the set of threads known by the SDK, we could use /relations on each thread root we know about; of course this would only grew over time, and result in the same slowness, but it might be sufficient to start experimenting with.

[edit] as Manu noticed and told me in private, this solution wouldn't be sufficient to be aware of the new threads that happened since the previous sync. We do absolutely need the SSS extension then.