Chat- and Document-style e-mail addresses and interactions

This is not really a feature proposal, more some thinking around the topic of co-existence of document-style mails and chat-style mails. Document-style mails are those with a subject, on which replies are threaded. Chat-style mails are those that are contact or group-contact based. Chat groups have a title but messages within are not threaded. Chat messages are shown linearly, at time of arrival. Topics tend to mix and rather be “people” based than “subject” based.

Some of us use two e-mail addresses, one with a Document-style and one with a Chat-style e-mail account. Others use the same account for both. The latter is known to cause several troubles, for example double-notifications if you have a document-style e-mail reader on your mobile, along with your Chat one. Or even worse, with Delta Chat’s current BCC-self logic, outgoing messages are notified in the document-style app if Delta was not fast enough to move the message away. We are not using an upload to the IMAP Sent folder because this doubles outgoing network traffic. In this githut core issue there is some discussion around the BCC-self logic which could be optionally turned off … but this is not what i want to talk about here.

This is rather about: what could we do to make using two separate addresses easier, nicer? ideas:

  • configure Delta Chat to know about the “document-style” address

  • if the document-style address forwards a mail to the Chat one, DC could show it as coming directly from the original sender, with some indicator. If you DC-reply to it, the In-Reply-To header be set properly so that the other side can know it’s from you. If the original message was a DC message we can make it rather seemless to have a DC-to-DC chat.

  • DC could allow to easily “bounce” a message to the configured document-style address (leaving the original message as intact as it can). The document-style app would get the bounced e-mail, and could reply to it.

  • If the doc-style and chat-style app use Autocrypt, they could share the cryptographic setup, so that e2e-encryption could be maintained.

  • if using the “+” extension, the two addresses could even be on the same IMAP account, say "x@domain.org" and "x+chat@domain.org", see also Lorenz’ blog post on + extensions with delta chat for how to configure something like this.

There are endless questions around this topic – but i think it’s an interesting one. I am a heavy user of both chat and doc-style e-mail, and think that even some small things could make the experience nicer.

1 Like

Juggling two separate accounts seems to unnecessarily complicate things for the users.
But for those that want and use separate accounts, why not just configuring the chat account as an additional account in the classic email client, to have access to the chats and be able to move and copy messages?

Concerning the double notifications, in many cases the problem found a perfect solution after disabling the notifications in the classic email client, and only have DC emit notifications. Quickly, those close contacts that should trigger alerts tend to also use DC. And classic email becomes again a check-when-time-is-right task.
But granted this simple “only chats trigger notifications” is not for everyone, so either

  • server side email filtering (as in your linked blog post), or
  • DC emitting notifications for classic emails

are still very valuable options, allowing for separate chat and classic email notifications without double notifications.

Juggling two accounts seems complicating things in particular, because it adds the new types of problems you mentioned.

Compare it with having a metric that distinguishes between (short and compact) chat-style versus document-style emails. (Something like 98% correct, 1% silent start-chat? prompts, and 1% wrongly opened tentative-chats that can be closed again with a simple touch of an “X”. But my guess is the errors could be about zero in reality.)

The metric would, for example, also still allow to (silently) show classic emails only as icons in the chats, available for reference (and interactions) and providing a chronological overview.

As a user I love to have everything (and everybody) in one place.

The only thing I do think about is how could I mark a message while I’m in Delta to make the message unread and return to it in mail app. Usually I just switch, start search for the message, reply it or unread and transfer to inbox. If it could be a feature of Delta, it would be neat!

1 Like

@searoso interesting. Moving back would probably best be done at IMAP-level, moving the message from DeltaChat to INBOX, and avoiding looking at it again. I agree that using a doc-style / chat-style scenario with one address is also worthwhile to think about. Under cleanup-server issues there are tentative discussions around automatically removing messages.

1 Like

Yeah, I collected that necessity as “Function to re-assign selected messages” here already.

1 Like

Oh, and the Chat-Version: false header was intended to avoid other clients to pull that email into the chat folder again.