Use the `In-Reply-To` header tag about deltachat-android HOT 23 CLOSED

Well, the problem may be, that it is not clear if a new message ...

• is a reply to the last message
• is a reply to another message
• is no reply at all
  ... so, we decided to skip the In-Reply-To: header at all. However, other ideas on this point are very welcome.

from deltachat-android.

You are right, the problem is not well defined...
On the other hand, I think that having a similar user experience in Delta Chat and threaded MUAs would be great and interpreting the new message as a reply to the last message would most likely reproduce the same thread structure in Delta Chat and other threaded MUAs.

from deltachat-android.

Conversations could be like gmail conversations. If the chat message would be only the body of the email, then we could open a new conversation with a contact by letting the system choose a default subject, or writing a custom subject. Then email clients would group the chat/mail conversations accordingly, and one could have many conversations with the same contact, with different subjects. If you do not what to write a custom subject, the subject could be as simple as "Chat 20170108 My Name - Contact Name".

from deltachat-android.

It seems related to: deltachat/deltachat-core#10

from deltachat-android.

I needed something like an In-Reply-To: header to detect email answers from different addreses (see deltachat/deltachat-core@2743420#diff-baa006768f71aa3f9e2aa8050f5b5c73R1465 ) and I tried to use the standard In-Reply-To: header but the result in normal MUAs was not very nice:

So, for now, I use a private X-MrPredecessor: header that does not disturb other MUA; if you have any ideas how to use In-reply-to in a prober way instead, you're welcome (I've added some ideas in the code comment linked above)

from deltachat-android.

A few alternatives comes to my mind, for example:

1- use a counter of In-reply-to's and brake the conversation not using In-reply-to when counter reachs 20 or so
2- don't use In-reply-to if more than 48 (configurably?) hours have past since last message.
3- make Delta a multi-conversations chat, I mean, one can have many conversations with each contact, not only one. So, conversations won't be infinite, you replay the thread you're talking about and start a new thread when the issue changed or the thread is too long (<- best option for me)

PS: I would love to help with patchs and tests for many of this and other ideas, but I don't know java or android programming, I even wasn't able to compile Delta, sorry!

from deltachat-android.

@r10s, I think the output you show is what we are looking for, probably you email client is not very friendly with long threads. Of course one cannot continue indefinitely to add replies to the same thread.

In my opinion @rizzopablo had a good proposal in fact (3) seems to be the best approach, equally close to email and chat behaviours, sadly it would somehow clutter your app with multiple conversations with the same contact. There would be users that won't like that approach.
I feel (2) can be a good compromise where the app somehow autodetect the end of a conversation.

from deltachat-android.

Of course one cannot continue indefinitely to add replies to the same thread.

But this is what will happen if Delta Chat just sets In-Reply-To: to the last Message-ID.

Setting up the subject so that some clients may recognize a conversation is also no good idea IMHO. it would bring us in a position always to react to changes done eg. by Gma'l.

A multi-conversation chat: Delta Chat should target people who are no experts and do no care about such things - moreover, for now, at least I have not the time to implement this.

Timeout: Yes, this was also my idea. But one should not use the last message as In-Reply-To but a well defined anchor, may be the first message send after 4 am local time - otherwise the thread would may have easily a depth of 1000 if a user send 1000 messages. Regarding pull requests: @rizzopablo the core is written in plain C and is far easier to build as a standalone CLI program...

I think for now, things are not perfect but they're okay.

from deltachat-android.

if messages starting from the second message use in-reply-to: <first-message-message-id-header> the mua can still show it as a group of messages and you can at least collapse it so it doesn't take up a lot of inbox space. it won't suffer from deep threading and you won't have to figure out which message is a reply of another :)

from deltachat-android.

I think the "right thing" to do is to use the References header like a mailing list does, so they can all be grouped together with the first message without needing to be in reply to a specific message.

from deltachat-android.

In fact, since ~ 2 month we use the References header for testing. There are some details that need more improvment, but in general, the thread-creation seems to work (code at https://github.com/deltachat/deltachat-core/blob/master/src/mrmimefactory.c#L169 )

from deltachat-android.

Excellent! I will have to build from source to get this version :)

from deltachat-android.

The change should already be in the F-Droid binary, however, building from the source of course allows to play around with some settings.
I did not found the time until now to finalize this stuff, eg. NEW_THREAD_THRESHOLD should be larger and maybe IIRC there were also be some other minor issues and cornercases, but sorry, I do not remember the details at the moment.

from deltachat-android.

Hmm, I installed latest from fdroid this morning... is there a setting I need to enable? Will keep playing with it

from deltachat-android.

It is enabled by default.

from deltachat-android.

I have 0.9.4 from F-Droid and I cannot make it generate a References header. I do see a X-MrPredecessor header in my received mails.

from deltachat-android.

Okay, this was a little bug that is fixed now (seems to be introduces in one of the last updates, I really know it already has worked some time), see deltachat/deltachat-core@09b07be for the fix; on F-Droid, it will be available in 0.9.5 or later then.

from deltachat-android.

Moreover, I increased the threshold to 24 hours.
Regarding multi-client: Different clients will create difference References:-header, maybe we will sync these headers some day, however one could also see this as a feature :) see deltachat/deltachat-core@f7d5c88 for details.

from deltachat-android.

Hi, everybody.
I think the "References:" header is the right choice for following a chat/thread. See description from DC help site "used standards":

RFC5322 - 3.6.4 - Identification fields - page 25/26:

---- excerpt start ----
The "In-Reply-To:" and "References:" fields are used when creating a
reply to a message. They hold the message identifier of the original
message and the message identifiers of other messages (for example,
in the case of a reply to a message that was itself a reply). The
"In-Reply-To:" field may be used to identify the message (or
messages) to which the new message is a reply, while the
"References:" field may be used to identify a "thread" of
conversation.
---- excerpt end ----

Details about how to build the fields (both) are described in RFC in this section.

from deltachat-android.

But DC should set the In-Reply-To header furthermore to be compatible with other MUA.

from deltachat-android.

But DC should set the In-Reply-To header furthermore to be compatible with other MUA.

well as mentioned at #36 (comment) this easily produces very depth threads with many MUAs. I think the References solution is a good compromise therefore. MUAs may combines the messages to threads or groups this way.

from deltachat-android.

Ok, I saw it but a litle too late ;-)

But by the way: Does a normal MUA not running into the same problem if You have a longer conversation back and forth?

Ok, normally I do not use conversations view in MUA so it seems to be no problem to act in a way without using In-Reply-To. I only came to my comment to indicate a proper formal use of the two headers: In-Reply-To and References.

from deltachat-android.

But by the way: Does a normal MUA not running into the same problem if You have a longer conversation back and forth?

Using References: seems to be a bit hackish, but it seems to work on many MUAs, instead of deeply nested threads as

A
|_ B
   |_ C
      |_D

it renders eg. in Thunderbird as

A
|_ B
|_ C
|_ D

When the references header for A, B, C and D are just equal. This "same reference" is re-calculated after 24 hours to avoid completely different messages being linked to an old context. See https://github.com/deltachat/deltachat-core/blob/master/src/mrmimefactory.c#L189 for some more details.

from deltachat-android.