Order of messages

A mail needs roundabout 8-10 secondes from sending to receiving.
If we use your idea all messages would be showed twice.

I think show messages twice is not the best idea. :wink:

It would be easier to add a user preference “sort by sent time or sort by received time”
But I’m not sure is it a really good idea to add too much options.

I think that will not solve your issues, but introduce issues for most users, I think there are something else happening with your group

I don’t know why should a correct chronological order create more issues.
And it would definitely fix the issue.

If I press the “send” button is exactly the moment when I want to say what I have to say.
And I expect it’s exactly on this place in the timeline. Not before the the sentence for what I react.

Every realtime conversation follow chronology.

Imagine a phon call. And the sentences will come in wrong order :joy:
So why should it be good to have it in a written “phone call”.

And a wrong order is a issue of DC.

DC based on E-Mail.
To say the Mail provider is the problem makes DC useless.

BTW. I don’t understand why you prefer sorting by receiving time.

No, most messages would not be shown twice because most of the time there are no conflicts in the order, since there is enough time between messages.

Webratte, I think it was explained earlier in the thread why sorting by receiving time can be bad, for example because a message might have been received just now but will instead be shown minutes or hours earlier and the user will not even notice it, because it’s out of view, because the current view is full of newer mails. Hope this helps

Of course, it’s always a compromise.
Still I think it’s a better compromice sometimes a message out of sight
but in correct chronological order instead broken conversations because
wrong order.

The message you talk about (sent e.g. 20 messages before) would be
visable but absolutely out of the context.
Maybe the question you answered with this message is out of sight.
And also it could be your (delayed) message now is shown behind a other
question and looks like the answere of this question.

A Chat (often times 3-5 words per message) like this ist very hard readable.

You see my point?

1 Like

Ah now I got you. I misunderstood you. That’s related to my bad English :wink:

example: I am traveling to work every day, there are no phone signal in the travel (road on the country) if I send a message when I was offline, and then I go online 2 hours later, I don’t want my messages to be hidden 2 hours ago in the conversation thread because I pressed the send button at that time but I am aware that I actually sent the message when I was online and expect a group of friends to see the message when I send it, I don’t want they get a “ghost” notification for my message and then get confused when they don’t see the message in the chat list that is simply a bad solution just because you just want to solve your problem you fail to see the big picture.

One possible solution to your problem that doesn’t ruin the experience of everyone else:
organize messages chronologicaly if they have X seconds of difference, otherwise just append to chat.

Regards,
adb

1 Like

If your message is a replay of a other message so the message you replayed would be miles away and nobody will understand it.

To bring messages in a wrong order you need only one second delay.

To bring a message out of sight you need a much higher delay.

So the possibility of wrong order is much higher.

And also if you sort by sent time, the order will be the same on all devices for all group members.
Sorting by receiving time it can happens you have on different devices different order.

As I said before. It’s aways a compromise.
So probably a user preference could be a solution.

i am in between: i think both received and sent - clocktime order are tricky. Basically a chat is a linear stream of messages – whereas in reality everyone has their own stream, depending on offline/online-ness and provider-ordering/queuing etc. Sometimes a message gets delayed, sometimes clocks are wrong etc.

There is a well-known fundamental problem in the computer science of distributed systems: replicating database entries between computers – and there is a standard recommendation or golden rule if you will: don’t use time-stamps if you can avoid it.

Synchronizing chat streams is a slightly different yet similar problem. In any case, we additionally have a UX constraint on mobiles that we want to show “new” messages, and avoid having to scroll or jump up.

One information we already have, btw, is what a user was (likely) seeing when they wrote a message – in e-mail jargon: each message has an “in-reply-to” reference to the last message shown on the screen. So in a sense, we know if somebody says “yes” what it (likely) refers to.

So it’s not all about sent/received time stamps and the main driving questions are UX questions, but a bit of taking into account the difficulty of distributed system synchronization (over smtp/imap) is useful.

2 Likes

I didn’t understood all.
But what I understood sounds logically and also complicated.
I believe you will find a way :+1:

Thank you for explain it.

Es ist einfach schwierig durch Zeitstempel (ausgang, eingang) eine global synchronization herzustellen. Das ist ein praktisches problem, und darüber wird theoretisiert. Ein Ausweg besteht darin, nicht über Zeitstempel zu arbeiten, sondern ueber Referenzen oder Durch-numerierungen. Damit läßt sich die Frage von “message ordering” nicht komplett beantworten, aber spielt eben eine Rolle. Von daher meine Skepsis alles über Zeitstempel zu “regeln”.

1 Like

I understand.
Hopefully you will find a way to keep the messages in a chronological order

I believe in you :+1:

1 Like

Hi, (not trying to re-ignite the discussion)
i was pointed here from github, i’m just adding my 0.02€’s)

first some definitions and references, as the first question: how do others do it? was never answered.
0. the problem is inherent to the way email works: it is an unsolved(unsolveable?) problem (cfr hpk)

  1. there is really no such thing as a ‘sent-time’ , there only is a ‘Date:’ header.
    which is under the sender’s (client) control and is easily, sometimes usefully, ‘changed’
  2. there are multiple received times, i.e. many 'Received: ’ headers
    these actually indicate which servers the message passed through, and when.
    these are reasonably accurate, trustworthy (but again there are multiple)
  3. FWIW: there is also the received time at the client - which is an entirely different thing.

so how does IMAP do it: AFAIK

  • the server shows message in the order they are received at the imap server. i.e. the sequence number (so neither 1. 2. or 3. , but 3. gets closest as the IMAP server’s time and order should be similar and the imap server is conceptually the receiving client.
    /but cfr point 0. this does not solve the ordering problem of messages in a shared chat, e.g. a chat with multiple parties on gmail and one on another smtp/imap combo will always be at risk of the gmail-crowd overtaking the others)
  • the IMAP SORT specifies using the Date: header, failing that, an INTERNALDATE and then the ORDER:
As used in this document, the term "sent date" refers to the date and time from the Date: header, adjusted by time zone to normalize to UTC. For example, "31 Dec 2000 16:01:33 -0800" is equivalent to the UTC date and time of "1 Jan 2001 00:01:33 +0000". If the time zone is invalid, the date and time SHOULD be treated as UTC. If the time is also invalid, the time SHOULD be treated as 00:00:00. If there is no valid date or time, the date and time SHOULD be treated as 00:00:00 on the earliest possible date. This differs from the date-related criteria in the SEARCH command (described in [[IMAP](https://tools.ietf.org/html/rfc5256#ref-IMAP)] [section 6.4.4](https://tools.ietf.org/html/rfc5256#section-6.4.4)), which use just the date and not the time, and are not adjusted by time zone. If the sent date cannot be determined (a Date: header is missing or cannot be parsed), the INTERNALDATE for that message is used as the sent date. When comparing two sent dates that match exactly, the order in which the two messages appear in the mailbox (that is, by sequence number) is used as a tie-breaker to determine the order.

so far for the ‘how do others do it’ googling… hope that clarifies that part.

as for a solution, from the poll it seems the majority is in favour of using the Sent time.
Assuming this is from the sending client’s perspective. the closest match would be the Date: header.

As far as the hidden message problem is concerned: couldn’t this be easier solved by showing an unread/unseen indicator as is common in almost all chat apps? typically bottom right with a scroll up indicator/button? All that would be required is the DC’s version of that functionality is aware that unread messages do not come in one contiguous chunk.

2 Likes

vertical visual indicator along one side of the conversation pane

or OOB xmpp only for timeline coherence (not content)

Sorting (the right way) is very important when it comes to groups.
e.g. I was in a group using an account A, but then I decided to change to my account B. I add my B account and left the group using A. Nothing too strange so far. But then, my friend X opened up DC after a couple days, he had lots of messages on our group. there were something wrong with sorting, somehow I’m not in his member list (with my account B), he sees my account A instead.

member list consistency is a different topic that some folks are trying to improve

But this part could be ease by better sorting imho.
I see consistency (as of v1.1.2) in the way I cannot chat in a group I’m not a member (e.g. When I send a message using account B, X receive an “unknown sender for this chat” message)

Just to keep this problem in the mind:

Probably on your devices it is in a other order.
Sorry I have to say I hate it, if messages in a absolutely wrong order.
In my example there are nearly no message in the correct chronological order. :roll_eyes:

And the same Chat on a other account:

We got an issue on github about this, I refereed the issue poster to this topic:
Error in messages order when synchronising #1562
https://github.com/deltachat/deltachat-desktop/issues/1562

Hi everybody,
are there news about this topic?
Some ideas how to solve the problem with the bad chronological order of messages?
I still got this again a few time. And I don’t like it.

@hpk know it :wink: