Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How should clients order a timeline composed of events from multiple rooms? #1520

Open
robintown opened this issue May 12, 2023 · 3 comments
Labels
improvement An idea/future MSC for the spec

Comments

@robintown
Copy link
Member

robintown commented May 12, 2023

Suggestion
It's come up in Element Web that we want to present timelines which aggregate the contents of multiple rooms, or in other words, 'overlay' the events from one room on top of another. To do this, the client needs to be able to establish an order between events from different rooms. The question is, how?

A few options come to mind:

  • Interleave the overlay events into the timeline based on their origin_server_ts. Different servers can have very different clocks though, and events in /messages responses certainly don't have to be in chronological order, so origin_server_ts is neither accurate to the local homeserver's view, nor monotonically increasing. For simple use cases involving only one homeserver, this will do the job, but in all other cases it's approximate at best and can result in the overlay events jumping around as the user scrolls back through history.
  • Use the age field on events to calculate a timestamp relative to the client's local clock, and interleave based on that metric. I don't entirely understand how homeservers calculate age, but I'd guess this approach is only marginally better than origin_server_ts, if at all.
  • If /messages were changed to use stream ordering (which apparently means "the order in which events arrive at the server"), then servers could include a timestamp in each event's unsigned data indicating when it received the event, which I believe would give us an accurate, monotonically increasing measure to sort by. It requires spec changes, though.
@richvdh
Copy link
Member

richvdh commented May 12, 2023

I'm not entirely sure this is a matter for the spec - it feels like a UX decision which is up to the client.

That said, if a client wants to use a particular algorithm which would require extensions to the protocol - then it would be a matter for the spec.

@richvdh
Copy link
Member

richvdh commented May 12, 2023

I don't entirely understand how homeservers calculate age

You're not alone: matrix-org/synapse#8429. (I agree that it's not necessarily any more reliable than origin_server_ts)

@MTRNord
Copy link
Contributor

MTRNord commented May 12, 2023

I'm not entirely sure this is a matter for the spec - it feels like a UX decision which is up to the client.

That said, if a client wants to use a particular algorithm which would require extensions to the protocol - then it would be a matter for the spec.

I think for the sake of user experience across the network it might be a spec topic. Since users tend to expect that they see the same view across their clients. So at least a SHOULD recommendation might be nice in the spec. And it would simplify building a new client :)

(edit: I am thinking of something similar like local echos)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement An idea/future MSC for the spec
Projects
None yet
Development

No branches or pull requests

3 participants