Message order in Matrix: right now, we are deliberately inconsistent • Hacker News Board

Re: Message order in Matrix: right now, we are deliberately inconsistent

#101

Post by snackbroken » Fri, Dec 06, 2024, 1:25 PM UTC

dzaima wrote: post #100

rkangel wrote: post #97

This article makes a logical step that I think is incorrect - that message order from the server is the order that a client then displays them in. Surely that's a presentation issue - you should display messages chronologically, regardless of what order you got them from the server? The author does touch on this a little bit, I don't see how that isn't the "obviously" correct approach?: > An alternative is to continu…

That "presentation issue" is quite an issue though; how do you sanely present to a user the fact that there are new messages to read, but they're scattered throughout the history of the message log arbitrarily far back? Granted, tacking them all at the end isn't necessarily good, but at least the user will see them, and timestamp indicators can help make sense of it. And I don't even see how placing them chronologica…

> how do you sanely present to a user the fact that there are new messages to read, but they're scattered throughout the history of the message log arbitrarily far back?

Like this[1]. It's how Element does it, and it's perfectly fine. Show the unread messages with a different background color until the user dismisses them if you must distinguish them from previously read messages. Alternatively, add a "jump to last unread message" button (and change the "jump to first" icon into a double up-arrow) that marks said message as read after jumping to it so you can just keep clicking it to hop to each one. If there's anything I'd change about this UI element, it's to display the number of unread messages in the green dot.

[1](https://imgur.com/UMboT1o)

Re: Message order in Matrix: right now, we are deliberately inconsistent

#102

Post by dzaima » Fri, Dec 06, 2024, 2:02 PM UTC

snackbroken wrote: post #101

dzaima wrote: post #100

Earlier quoted context omitted.

That "presentation issue" is quite an issue though; how do you sanely present to a user the fact that there are new messages to read, but they're scattered throughout the history of the message log arbitrarily far back? Granted, tacking them all at the end isn't necessarily good, but at least the user will see them, and timestamp indicators can help make sense of it. And I don't even see how placing them chronologica…

> how do you sanely present to a user the fact that there are new messages to read, but they're scattered throughout the history of the message log arbitrarily far back? Like this[1]. It's how Element does it, and it's perfectly fine. Show the unread messages with a different background color until the user dismisses them if you must distinguish them from previously read messages. Alternatively, add a "jump to last u…

This might not sound entirely awful in theory, but I'm fairly certain it'd be entirely awful in practice for a good amount of users.

Having colored backgrounds might look ugly and thus immediately make that a non-option, and, even if viable, are still problematic if new messages are added while reading, as you'd need multiple colors for the reading pass the user's on.

Having to click a button repeatedly is also likely to be entirely unacceptable UX for most users, never mind that you're essentially recreating the receive-order message list, just without displaying it in a sanely traversable format.

This problem is hard enough with linearly added messages to the end, making it 10x worse is awful.

Re: Message order in Matrix: right now, we are deliberately inconsistent

#103

Post by OskarS » Fri, Dec 06, 2024, 2:33 PM UTC

kelnos wrote: post #77

danpalmer wrote: post #3

This is something that many chat apps get wrong and I'm not sure this article is moving in the right direction. The UX is fairly clear in my mind: 1. All up-to-date clients should be displaying the same message order. 2. A single client should not send messages in the wrong order. Yes a client may be out of date and therefore show something different, but once it becomes up to date it should be showing the same state…

Agreed, absolutely. I was surprised by the author's aside that mentioned a colleague that disagreed, claiming that it's ok or even useful (what?) that two clients (or even the same client in different situations) could show different message orderings... and acknowledging that this point is debatable. It's not debatable! There is, actually, in reality, one true message ordering (at this time I think we can safely ign…

> (This does mean that clients connected to different homeservers might see different orderings; this is unfortunate but probably unavoidable. But clients connected to the same homeserver should all see the same ordering.)

I don't think it's unavoidable at all, this is exactly the kind of problems CRDTs solve beautifully. If you model your chatting as a CRDT (basically, each message has a Lamport timestamp on it, and you have some sensible way to resolve ties deterministically), then assuming all peers have gotten all messages, the ordering should be perfectly consistent. What may happen is that you type a message, press "enter", and then some message might pop up before that when everyone finally sync, but I think that is acceptible UX, I see version of this in things like Slack and Discord frequently.

All peers having the same message order assuming they all have received the same messages is absolutely required for a chat application in 2024, distributed or not.

Re: Message order in Matrix: right now, we are deliberately inconsistent

#104

Post by moritzruth » Fri, Dec 06, 2024, 3:23 PM UTC

timokoesters wrote: post #44

I'm the author of the spec issue this blog post is based on: https://github.com/matrix-org/matrix-spec/issues/852 In my implementation for the Conduit Matrix server, the /sync order is used for everything. The timeline is just one list that grows on one end for incoming events and on the other end for backfilled events. I think it's important that the message order does not change, because that's very difficult to co…

A few years ago, I started writing a Matrix client library for Kotlin. At one point, I had to make an API decision based on how messages are ordered. When I found this issue, I subscribed to it and planned on continuing with my library when the spec was clarified. Given how foundational this spec unclarity is, I thought it wouldn't take too long.

Well.

Re: Message order in Matrix: right now, we are deliberately inconsistent

#105

Post by toast0 » Fri, Dec 06, 2024, 3:32 PM UTC

kiitos wrote: post #89

toast0 wrote: post #26

Earlier quoted context omitted.

I'm pretty sure this is actually impossible in a distributed system with independent operation, and if it were possible, it would be terrible UI anyway. Problem one is if you want to order events chronologically, you need to precisely decide what the time of the event means. Probably not the time the client hit send, because you can only measure that on the client and client clocks are at best approximately accurate.…

Give up on the idea of "the timestamp" of an event. There is no such thing. Clocks are unreliable, and even if every clock in a system is perfectly in-sync (via atomic transponders or whatever) they're still subject to speed-of-light discrepancies that make it impossible to define "the time" of any event. Two nodes separated by 10000km require ~33ms to send information in one direction, and ~66ms to do a roundtrip. S…

> Logical ordering of events in a distributed system is a solved problem. The solution is vector clocks (or something like them).

Vector clocks don't solve this problem, as they only provide a partial ordering. When multiple messages are in flight in the same 'simultaneity window', different observers may receive them in different orders and vector clocks can't determine a consistent order of those events.

Vector clocks could be used determine the order is inconsistent. But what do you do with that information? You might likely have follow on events where A and B are unordered, and A1 was sent only seeing A, B1 sent only seeing B, and C was sent seeing A and B without seeing A1 and B1. It only gets more complex from there.

I'm not a UX person, but I can't imagine how to show this to users without causing massive confusion and information overload. There's a very small set of people that have studied distributed communication that would get this. And I haven't seen any UI that shows similar information in a coherent way... maybe git graphs, but I don't see how you make that fit on a phone screen where you're having a group chat.

Maybe just some indicator that says other people may see these messages in a different order, but then if it's not an immediately obvious signal, it's not really going to help users understand.

Re: Message order in Matrix: right now, we are deliberately inconsistent

#106

Post by moritzruth » Fri, Dec 06, 2024, 3:48 PM UTC

wolrah wrote: post #68

duskwuff wrote: post #7

Earlier quoted context omitted.

What I think you're missing is that Matrix runs as a distributed system. There's no central authority to assign IDs to messages, and it's possible for a single group chat to run in a split-brain configuration if two homeservers lose connectivity to each other. When those homeservers reconnect, users connected to each one will see messages appear "in the past" which were sent by users on the other side of the split.

Perhaps I'm wrong about how Matrix works, but my understanding was that at least public rooms still had a "primary" homeserver, like for example I can connect to #debian:matrix.org from any number of federated servers but matrix.org is still where that room "lives". If that understanding is correct, then IMO the answer is simply that the canonical timeline is what that server says it is. Poorly connected users or tho…

AFAIK there is no primary homeserver. The human-readable name of a channel has a homeserver part, but this is only for discovery purposes and maps to an alphanumeric random ID.

Re: Message order in Matrix: right now, we are deliberately inconsistent

#107

Post by dzaima » Fri, Dec 06, 2024, 3:59 PM UTC

dzaima wrote: post #102

snackbroken wrote: post #101

Earlier quoted context omitted.

> how do you sanely present to a user the fact that there are new messages to read, but they're scattered throughout the history of the message log arbitrarily far back? Like this[1]. It's how Element does it, and it's perfectly fine. Show the unread messages with a different background color until the user dismisses them if you must distinguish them from previously read messages. Alternatively, add a "jump to last u…

This might not sound entirely awful in theory, but I'm fairly certain it'd be entirely awful in practice for a good amount of users. Having colored backgrounds might look ugly and thus immediately make that a non-option, and, even if viable, are still problematic if new messages are added while reading, as you'd need multiple colors for the reading pass the user's on. Having to click a button repeatedly is also likel…

And then there's the issue on switching between clients (e.g. PC and phone) or otherwise having client state lost - if the complete reading progress isn't saved server-side, then it becomes entirely impossible to restart reading; whereas with a receive-order log you can at least manually scroll to the message you read last and continue downwards.

That said, a similar problem already exists with edits, and a universal solution for arbitrary insertion should also be able to improve arbitrary edit notifications.

Re: Message order in Matrix: right now, we are deliberately inconsistent

#108

Post by toast0 » Fri, Dec 06, 2024, 4:14 PM UTC

aeonik wrote: post #56

toast0 wrote: post #26

Earlier quoted context omitted.

I'm pretty sure this is actually impossible in a distributed system with independent operation, and if it were possible, it would be terrible UI anyway. Problem one is if you want to order events chronologically, you need to precisely decide what the time of the event means. Probably not the time the client hit send, because you can only measure that on the client and client clocks are at best approximately accurate.…

As long as the speed of light remains constant for all observers, who cares if everyone agrees on simultaneity? Distributed systems don't need to know what time it is, just what happened . Well known systems are implemented this way, and the UI is great, people barely even notice.

The problem is that we don't just want to know what events happened, but also the order of events.

Between the posters in this group, we've got some ideals we'd like to meet

a) messages should be displayed as soon as possible when they arrive (this one isn't written much, but I think it's generally agreed)

b) messages should be displayed in a globally consistent order

c) message order should not change after display / newly arrived messages must be at the bottom/top

Unfortunately, we can't meet all these ideals unless instant messaging becomes actually instant instead of just pretty fast messaging subject to the speed of light and other sundry delays.

You can get all the properties if you serialize messages through some single queue somewhere, but of course that means additional delay and a spof.

You can most likely get b and c if you compromise a, and just don't display messages for long enough that you probably have everything and can order it according to the gloablly consistent ordering algorithm.

If you compromise b, you can definitely do a and c. Messages go to the end when received. Easy peasy. You can't leave placeholders for messages that will be sorted earlier but haven't arrived yet, because you generally won't know they exist until they arrive; although there are some cases where you could know. If a user receives message X and sends message Y, but due to delays and what not, you receive Y before X ... Y could indicate the presence of X, and a reciever who gets Y first could reserve a place for X... but that doesn't work for simultaneous messages.

If you compromise c, you can do a and b, messages are inserted into the ordered list on arrival based on the consensus ordering algorithm. Easy enough.

Of course, there's not widespread agreement on b and c. So half of the thread is people saying b is clearly non-negotiable, another half is saying c is clearly non-negotiable, and the other half is saying why can't we just have everything we want.

Re: Message order in Matrix: right now, we are deliberately inconsistent

#109

Post by rkangel » Fri, Dec 06, 2024, 4:25 PM UTC

dzaima wrote: post #100

rkangel wrote: post #97

This article makes a logical step that I think is incorrect - that message order from the server is the order that a client then displays them in. Surely that's a presentation issue - you should display messages chronologically, regardless of what order you got them from the server? The author does touch on this a little bit, I don't see how that isn't the "obviously" correct approach?: > An alternative is to continu…

That "presentation issue" is quite an issue though; how do you sanely present to a user the fact that there are new messages to read, but they're scattered throughout the history of the message log arbitrarily far back? Granted, tacking them all at the end isn't necessarily good, but at least the user will see them, and timestamp indicators can help make sense of it. And I don't even see how placing them chronologica…

There are two things that I'm pretty sure are true:

- People think that messages are a timeline and are in chronological order. For non distributed messages (Teams, WhatsApp) that's the reality, and people don't read message timestamps. Old messages being put at the bottom is confusing.

- Matrix is distributed so message can arrive out of order (sometimes with quite a delay)

Those two things together means that the client HAS to solve this display problem.

Re: Message order in Matrix: right now, we are deliberately inconsistent

#110

Post by dzaima » Fri, Dec 06, 2024, 5:13 PM UTC

rkangel wrote: post #109

dzaima wrote: post #100

Earlier quoted context omitted.

That "presentation issue" is quite an issue though; how do you sanely present to a user the fact that there are new messages to read, but they're scattered throughout the history of the message log arbitrarily far back? Granted, tacking them all at the end isn't necessarily good, but at least the user will see them, and timestamp indicators can help make sense of it. And I don't even see how placing them chronologica…

There are two things that I'm pretty sure are true: - People think that messages are a timeline and are in chronological order. For non distributed messages (Teams, WhatsApp) that's the reality, and people don't read message timestamps. Old messages being put at the bottom is confusing. - Matrix is distributed so message can arrive out of order (sometimes with quite a delay) Those two things together means that the c…

I'd add:

- People think that messages they haven't read will be below ones they have.

which is in direct conflict with your first point. Which of the two is stronger probably depends on the person.

And indeed it's a tradeoff between confusion about chronologicality vs confusion about what's been read, and which is more important will again depend on the person, and the specific discussion. If not reading timestamps is a large concern, there could always be some explicit separator in the log (e.g. a line of "In the past at 2024-12-05 12:34:56"; in my client I have a funny "X (hours|days) earlier..?" when there's a negative time delta between messages, as opposed to a "X (hours|days) later..." on a large positive time delta, though a date would probably be more sensible; and for what it's worth I also have a `/sort` command to reorder the visible log chronologically).