You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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)
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:
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, soorigin_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.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 calculateage
, but I'd guess this approach is only marginally better thanorigin_server_ts
, if at all./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.The text was updated successfully, but these errors were encountered: