Received deferred messages are impossible to spot in a chat

[DarkCat09]

• Operating System (Linux/Mac/Windows/iOS/Android): Android
• Core Version: 2.48.0
• Client Version: ArcaneChat 2.48.0-foss

An attempt to fix order of messages coming from different relays (#8031) led to another UI/UX bug.

What happened: one relay (B) couldn't connect to another (A) and deferred some mail. Then eventually federation issues resolved and the mail was delivered. But a user from relay A already wrote some messages to B, so B's deferred message is not the last one in their chat.

So here's the bug:

Expected behavior

I expect any newly received messages (even if deferred and actually written before my last one) to appear at the bottom of a chat, not somewhere in the middle.

Actual behavior

B's deferred message got sorted by its sender-side timestamp and, on the A's side, popped up in the middle of the conversation (right where it should've been placed if the connectivity hadn't been broken).

Additionally, a mark "1 new message" is displayed above the last 1 message which is A's msg, not the B's one, because it's not the last in the chat due to this sorting order.

So, there's no way for A to even spot the message they've just received, because it's lost somewhere above and not marked by "1 new message" (instead, this mark is mistakenly shown above A's own msg, because it was the last msg in the chat).

Please see the attached screencast for a better description.

Steps to reproduce the problem

To artificially reproduce this, you'll need two different chatmail relays (A and B) and one profile on each of them (users A and B) with a DM chat between these users.

1. Temporarily block relay B on the relay A firewall, e.g. iptables -A INPUT -p tcp -s 1.2.3.4/32 -j DROP.
2. On user A's side, send some messages.
3. Then, on user B's side, send some messages too.
4. On user A's side, send some messages again (so, when later sorting by timestamp, these will be at the bottom).
5. Unblock relay B, iptables -D INPUT 1.
6. Wait half a minute, click "Resend" on user B's messages if they still don't arrive to user A.
7. Notice that user A received the deferred B's messages sent in the step 3, and they are sorted above A's messages sent in the step 4, and the "X new messages" mark incorrectly points to those A's msgs from step 4.

Screenshots

dc_repro.mp4

Logs

N/A

[DarkCat09]

Actually federation issues is not the only way to trigger the bug.

Little network delays happen in regular conditions anyway, both in s2s and c2s.
So, when you and someone else send messages in the same chat almost simultaneously...

What other messengers usually do: your message is displayed earlier, because the client has known about it earlier, while the received (someone else's) message is placed below yours, because was received later.

What DeltaChat currently does: friend's message has an earlier timestamp (it differs by a second indeed, okay), so, even despite you've already sent your message and the client has rendered it, the friend's message (when it is received) suddenly appears above yours. That looks so weird.

[iequidoo]

What other messengers usually do: your message is displayed earlier, because the client has known about it earlier, while the received (someone else's) message is placed below yours, because was received later.

Other, particularly, centralized messengers, can just sort messages in the order the server receives them, the server then can deliver messages to the client in the same order. Before multi-relay, the same was possible for Delta Chat. Now it's imposible because we can't wait for one relay to fetch messages from another, this would at least add unwanted delays. We could preserve the old sorting if the user has only one (published) relay, but such conditional "solutions" only complicate the code.

Note that before, we also resorted messages by "Date", but only fresh (unseen) ones. This may also be questionable however: imagine that Alice sent her message earlier than Bob, but Bob had been already offline for a week and hadn't seen new messages, so his reply is more "stale".

[link2xt]

Let's say there are three users, A, B and C, each on its own relay (also named A, B, and C). A, B and C are in the same group. A and B chat actively, but federation between B and C is broken, so C receives only messages from A. Then federation restores and C finally receives also missing messages from B. In this case we do not want to sort messages from B to the end of the chat, but in between A's messages, so C can read the dialog between A and B and not all the messages of A followed by all the messages of B.

I think ideal federated messenger designed from scratch should sort messages topologically based on References (ignoring the case of someone maliciously forming a loop, let's say clients are behaving correctly) with ties resolved based on the sender timestamp. Essentially what git log does when displaying commit tree. This is not easy to implement now because currently all the ordering happens by a sort_timestamp value. When everyone has correctly set clock just sorting by the sender timestamp is indistinguishable from topological sort. Implementing sorting by References is theoretically interesting, but not a priority IMO because this will likely introduce a lot of complexity and there are other things that break when you have wrong clock, e.g. locally generated info messages have no concept of referenced messages, there are timestamps sent around in the member list and sync messages etc.

Then there is a problem of notifying the user of messages that arrive late, either because of multi-relay, or because of temporarily broken federation. This looks to me what the problem is about, "1 new message" should point to the first unread message, there could be an arrow pointing to the top with a counter of off-screen unread messages jumping to the first unread one. There is a very similar issue about improving handling unread messages at #7965, especially not marking all the messages as "noticed" just because the chat is open. This now needs a redesign so we don't fix some cases while breaking the others.

[iequidoo]

With sorting purely by Date we at least need to highlight somehow new messages, maybe the user doesn't want to re-read everything. But the problem with sorting by Date is that it's less informative: it duplicates what is already displayed on message bubbles and the old sorting (by Received, basically) is better when after some time you need to understand how incoming messages are ordered around yours logically, i mean cause-and-effect relationship. Also unencrypted chats became "modifyable": before, it was impossible to edit/delete/backdate messages there. Unencrypted messaging isn't a priority however, i rather mean that it'd nice to have non-modifyable chats for contacts that you can't completely trust.

[link2xt]

But the problem with sorting by Date is that it's less informative: it duplicates what is already displayed on message bubbles and the old sorting (by Received, basically) is better when after some time you need to understand how incoming messages are ordered around yours logically, i mean cause-and-effect relationship.

When everyone has correctly set clock, sorting by Date already ensures that replies always follow the messages replied to.

[iequidoo]

When everyone has correctly set clock, sorting by Date already ensures that replies always follow the messages replied to.

But if a message appears above your reply, that doesn't mean that your reply was made taking that message into considration. With sorting by Received it was so, i.e. the whole context of your reply was clear.

[link2xt]

But if a message appears above your reply, that doesn't mean that your reply was made taking that message into considration. With sorting by Received it was so, i.e. the whole context of your reply was clear.

Incoming message that arrives later also was sent without taking your outgoing message into consideration. According to this logic it should be sorted above your message.

[iequidoo]

Incoming message that arrives later also was sent without taking your outgoing message into consideration. According to this logic it should be sorted above your message.

For incoming messages it was never possible to completely understand the message context, you could only see the quoted message. But with sorting by Received it was possible for outgoing messages which is not easy now (you should look into Message Info to compare "Received" time).

[iequidoo]

Another scenario which is probably worse now with sorting purely by Date: imagine A1 and A2 using relay A and actively chatting and B1 and B2 doing the same on relay B. This happens in the same group, but federation between A and B is broken for some time and then restored, so all members get their conversations merged/mixed and now it looks like all participated in the same conversation with each other. With sorting by Received things were probably clearer because conversations would appear in different parts of the chat, i.e. it was clearer that there was a network split for some time and members on different relays didn't see each other's messages.

[iequidoo]

Another problem with sorting purely by Date: if you have the clock running a bit ahead, say, by 10 secs, and you're actively chatting, you'll have incoming messages not referencing your ones in In-Reply-To inserted above your messages. This may happen because these incoming messages are replies to other messages (see tweak_sort_timestamp()) or your messages are delivered with delay.