Random Subject Lines

Delta Chat version

<= 1.12.0

Expected behavior

Subject line is handled correctly, most especially when sending messages to users who are using ordinary MUAs (not Delta Chat). I have noticed bizarre subject lines that have nothing to do with the subject of the current message, but chosen only because some message in the distant past had that subject. The subject should be extracted from the current message text, or simply set to "Message from " (as I have seen on occasion).

As a work-around to avoid inappropriate and confusing subject lines, I have had to create Delta Chat “groups” which always set the same subject line.

Also, subject lines should not begin with "Chat: " (I don’t know if current versions still do this, however.) Starting an email subject line with "Chat: " is extremely unexpected and confusing to users of ordinary email programs.

I notice that there are a couple of related feature proposals which may overlap with this topic, but are not exactly the same. For example, I don’t necessarily think that making the user select a subject line is the way to go; and neither is the simple “do not change the subject” (subjects, by their nature, change a lot, and in-reply-to headers should deal with threading regardless of subject).

Also, this only applies to unencrypted messages, as setting the subject line on encrypted messages leaks information, obviously.

Actual behavior

Inappropriate subject lines leave users of ordinary MUAs confused.

Steps to reproduce the problem

  1. Send a series of one-on-one messages to an ordinary MUA user
  2. Check the subject lines generated or set or used by Delta Chat.

Thank you for your report. I think this issue has been filed already:

It should be fixed in the next version.

It’s not threading I’m concerned about per se, but incorrect subject lines.

For example, a message concerning last night’s big game should not have the subject, “I need your bank account details.”


Hi David,
I believe this was a recent and deliberate change to have persistent subject lines from one message to the next. This fixed the problem that many MUAs display messages with different subject lines as distinct conversations/threads, regardless of the threading headers. I’ve seen at least Gmail and Outlook exhibit that behaviour.

So the previous behaviour of setting a new subject for each message of the form "Chat: " made long conversations extraordinarily spammy to ordinary e-mail users. A good experience communicating with ordinary e-mail users is, IMO, a very important property of Delta Chat.

So while I think this new behaviour is a big improvement, I agree with your complaint that sometimes this leads to inappropriate subjects in subsequent conversations. As a motivating example that’s better than yours, try “Re: Bad news about Grandpa”.

It’s an impossible problem to solve perfectly - mapping a purely linear subject-less medium (chat) into a much richer medium (e-mails). You can never automatically figure out when a conversation “ends” for certain. But I think there’s room for improvement. I’ve been putting together a design in my head, and I might even put it into a PR once I have the free time. How about this:

  1. If you archive a 1-to-1 chat, the subject line is reset the next time you message the recipient. I think it’s fine to equate archiving with “I’m done talking to this person for now, the next time I talk to them it’s about something different”.
  2. If a chat has been idle for some amount of time (24 hours, 48 hours?), the subject line is reset.
  3. Power users can forcibly reset the subject by formatting the text of a new message in the exact same way that incoming e-mails with new subjects are rendered i.e. “This is a subject - this is the body”.
  4. When picking a brand new subject for an outbound message, go back to the previous scheme of inferring the subject from the first few words of the text. It’s not perfect, but it’s strictly more informative than “Message from David Trudgett”.

I think this is probably the best we could get, without turning Delta Chat into something it’s not (a Proper E-mail Client). What do you think?


Gidday, Richard,

Yes, there are some very good suggestions there. It’s a pity that Google and Microsoft are not concerned with doing the right thing, but only with pandering to the majority who don’t know how to use email (“reply to all”, as another example, appears to be a struggle for the vast majority).

I don’t know if “spammy” is quite the right word choice for the inability of people to deal with a larger number of emails than “usual” (‘spam’ is unsolicited commercial email). However, you are right that there is a definite impedance mismatch with users’ expectations for email, versus DC’s instant messaging paradigm. This is compounded by people not knowing how to use email properly (for example, unable to create filters to automatically deal with certain emails, unable or unwilling to “reply all” to a group email, and the opposite, unable or unwilling to send private replies privately, instead of to the whole group).

I completely agree that DC promotes interoperability with normal email users, and so should make every reasonable effort to ensure that the experience is acceptable to those users of typical MUAs (any non-Delta Chat MUA, I suppose).

Unfortunately, inappropriate subject lines are the norm, rather than the exception, as one might think after reading by my previous comments and explanations. When one sends a message (email) the first time in a week or two weeks, it is not acceptable to have the subject line from last week or the week before that (which quite likely was not very appropriate even back then). Your suggestion about the timeout behaviour would appear to be a reasonable fix for that issue.

One reason this behaviour is unacceptable is that the receiver has no idea that you didn’t set the subject, but that your “silly” email program did it for you, and not only that, but that you, as the sender, have no idea what the subject line actually is. (Impedance mismatch.)

Although uninformative, it is much more acceptable (than the current practice), and in line with the instant messaging paradigm, to always set the subject as “Message from NAME”. Or possibly better, “Instant message: NAME <=> NAME”, which would thread just nicely on broken MUAs that thread on Subject instead of in-reply-to headers.

Regarding your specific ideas or suggestions, in order.

  1. This seems a quite workable idea. I think you are right that after archiving a conversation, there would be no reasonable expectation that the Subject line should remain unchanged. A possible exception may be if one receives another reply to a chat that has been archived.

  2. A user-configurable chat idle time in hours or days would be ideal, too. I assume most people would be happy with an idle time between one and seven days (or infinite, if they don’t wish to use that feature).

  3. A simple “Subject: This is the new subject” followed by a new line seems easy both on the user and the developers. Documentation would alert the power user that this may start a new thread in broken MUAs. To actually start a new thread (which is orthogonal to changing the subject, instead of the word ‘Subject’, use the word, ‘Thread’: “Thread: This is the subject of the new thread” followed by a new line. A subject that is too long would begin to print on screen in red.

  4. Obviously, this only applies in the presumably usual case when the user does not explicitly set the new Subject (after archiving a chat, for instance, or the very first email sent to a particular recipient).

Yes, I don’t think anyone wants to turn DC into a “proper” email client, yet we agree that we do wish to avoid alienating those with whom we are communicating! :slight_smile:

Here is another important impedance mismatch to think about. When the remote user sends you an email, or replies to an email, they often set or change the Subject, and sometimes this_information_is_not_repeated_in_the_body or alternatively, you need to see the subject line in order to interpret the body correctly. This will result in incorrect communication because the DC user never sees the subject! (Unless, like me, they sometimes check in another MUA.)

I believe this probably means it is mandatory for acceptable interop with normal MUA users, that the current subject line be always visible in some way! And if it’s going to be visible, it might as well be editable, too. (Obviously, this is not required or desired for plain Delta Chat to Delta Chat messaging.) Having the subject appear while hovering the mouse over a message might be an acceptable compromise for desktop Delta Chat, but obviously not for mobile.