[rkangel]

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 continue providing events in any order, but add some kind of order number that allows clients to sort events into /sync order. MSC4033 proposes this.

[dzaima]

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 chronologically would be particularly useful - given a netsplit there's not gonna be any relation between the previously-present and delayed-received messages at that time interval anyway, you're just interleaving two entirely different discussions for no reason. (ok maybe there can be some unidirectional delay where it could maybe be useful, idk)

[snackbroken]

> 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)

[dzaima]

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.

[dzaima]

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.

[rkangel]

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.

[dzaima]

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).