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