As long as the user does not have a given chat open, the client should be free to reorder all unread incoming messages there according to timestamp.
Otherwise, when a message is received with a timestamp that is earlier than the most recent one on that timeline, clearly mark it in a special way. Possibly also provide an information bubble that explains that this can be caused be resending.
Possibly also provide a button next to it that would make the message jump to its place in chronological order. Or duplicate the message at both places: show it chronological as a normal message and also at the time of reception as a dim one as if it was a reply to the original one (i.e., so a jump-to button was shown).
If an incoming message has a timestamp noticeably in the future (i.e., more than a few minutes off), similarly provide a button to make it stick to the timeline at the time of reception.
IDK, is it something that’s needed at all? Would users really want to be shuffling messages around basically manually? Is it not enough to just have the “sent” and “received” timestamps, which we do have already? Maybe it would be better to try to fix or improve upon the underlying issue?
It is not possible to “fix” the underlying issue automatically. No platform had succeeded in coming up with a solution for this and definitely no decentralized system will.
Anyway, the above workaround is the only “fix” I can see, but feel free to chime in if you know any more. The current behavior of displaying messages in the order of arrival causes confusion and results in an unreadable timeline even (especially?) in case the user did not have the app open for a long time.
The underlying “issue” (rather property) is other than during longer outages and federation issues, it is quite normal for servers to take a variable amount of time to deliver messages to each of the recipient. In case of more rare, but not exceptional circumstances, it is plausible that a subset of participants would see a different timeline than others by just a few minutes of jitter. In case of delivery failure (whenever a chatmail server had just a tiny downtime or connectivity issue), the origin server will keep retrying to submit the same message a few more times, but it will delay quite a lot between each attempt (not sure how chatmail is configured, but it was usually hours for classic mailboxes). This could be somewhat improved by the other issue, because the messages could be somewhat sorted based on the hash chains, although it’s inferior to the sender timestamp as it’s only a partial ordering.
A way of enforcing a global timeline would involve dedicating a specific user (the single owner/admin?) or a bot account and then only consider our message “sent” after they have responded with an MDN and a signed certificate for others and only show our outgoing message grayed out then. This scheme actually degrades to using a single relay bot account to forward each message to all members and that would also not require implementing anything special (other than the missing context detection outlined in the other issue). I do not consider this workaround desirable in context of Delta Chat.