Subject of emails

Feature Proposal
34

+1

DC uniqueness - it is simplify email messaging AND automatic encryption.

Attempt to seat on two different chairs, located in opposite corners of room, that what this tread all about IMO.

KISS principle - do one thing, but do it best.

If one need full feature email messaging, then he/she should use full feature email client such as thunderbird for example that allows feature one needed.
Personally I really don’t like that DC attempting to act as a normal email client for un-encrypted messaging. It defeat the whole idea of simplified messaging, idea to be a secure chat application. It may create situation when encryption will be broken logically by simply messing encrypted and un-encrypted messages.

Chat != email

Use the right tool for a job - is an old wisdom verified by time.

There are plenty of email clients that satisfy requirements to supply custom subject as well supporting encryption. Why one more ?
Just download a normal email client and use it.

Blue Mail, Email by Edison, Microsoft Outlook, Gmail, Aqua Mail, Email TypeApp, K-9 Mail, myMail, Newton Mail, ProtonMail… and so on, just choose your favorite tool instead of breaking unique features of DC and move it to the list of highly competitive apps listed above.

Adding geek’s “-” or “|” separators easily can be abused by people who have no clue about such proposed feature (I think it is majority of users who don’t like to read documentation) and DC will easily became non encrypted chat app.

While DC is technically a MUA, the gist of this app, that it is a chat app.
There no such thing as a subject in chat applications.

One more time: Use the right tool for a job - is an old wisdom verified by time.

2 Likes
35

Please stay at the topic. Your post could belong here: [Discussion] Make DC a replacement for MUAs?

And there are people who would like to use DC as MUA (-> email interop) (like, me); we already had all pro and con arguments in the linked thread I think.

1 Like
36

@AlexJ the problem is that Delta Chat can’t work nicely in a multi-client setup (Delta Chat + classic MUA): notifications from your classic MUA and from DC for the same message, self-bcc copy notification from your classic MUA, double downloading of messages, etc.
for this reason people would like to have the right tool for the job and use only Delta Chat, anyway as @Hocuri said this probably better go to [Discussion] Make DC a replacement for MUAs?

2 Likes
37

I think all your concerns can and need to be well incorporated in the right solution.

@webratte

I simply don’t like if the subject is made of a part of the body.

  • That should and is already never done for encrypted messages (subject seen in classic clients is something like “autocrypt message”, and these messages should be imediately get the “seen” flag to make them less disturbing in classic clients: IMAP strategy to chat within the email ecosystem ).
  • Answering unencrypted messages: Subjects of chat-initiating messages that are not repeated in the body (if one exists) should never be changed (replies in such threads re-use the same subject like classic email clients, if not manually overridden).
  • Starting a new unencrypted chat-thread (sending a message): Deltachat is a chat app based on opportunistic autocrypt. Currently, that means, with the default preference “opportunistic prefer encrypted if possible”, chat messages are sent to unknown recipients with the short text immediately visible in the subject. Configuring the “require encrypted” preference should change (disable) this.
  • A way to manually specify a subject case-by-case should be available. (see the “-” proposal)
  • A preference to “always use classic subjects when starting unencrypted chat-threads” may be a good option, once some GUI editing field is supported (Subject and Group names · Issue #128 · deltachat/deltachat-core · GitHub) and may at the same time enable that GUI when sending unencrypted.

@AlexJ

DC uniqueness - it is simplify email messaging AND automatic encryption.

Exactly, and that means to be able to communicate seamlessly with all types of email clients, classic and chat clients.

KISS principle - do one thing, but do it best.

That’s why deltachat-core only provides the messaging programing interface (API) to the email system, and needs to incorporate all the functionality to make it operate smoothly within the entire email world.

Personally I really don’t like that DC attempting to act as a normal email client for un-encrypted messaging. It defeat the whole idea of simplified messaging, idea to be a secure chat application. It may create situation when encryption will be broken logically by simply messing encrypted and un-encrypted messages.

Your use-case (Use-cases, chat rules and configuration options) then sounds like you may want to use the “require encryption”, or maybe better a “prefer encryption, without fallback to unencrypted” preference, or “secure chats”.

Adding geek’s “-” or “|” separators easily can be abused by people who have no clue about such proposed feature (I think it is majority of users who don’t like to read documentation) and DC will easily became non encrypted chat app.

I currently don’t understand why or when using “-” (and even “|”) should trigger a fallback to sending unencrypted messages, that would be wrong IMHO. For those using chat apps (no subject field), there won’t be any visible difference, anyway.
Concerning the “geekness”, that’s only the quick option for the email aware users, directly accessible by typing the messege. GUI is possible later: Subject and Group names · Issue #128 · deltachat/deltachat-core · GitHub

While DC is technically a MUA, the gist of this app, that it is a chat app.
There no such thing as a subject in chat applications.

A very unique DC feature is the large existing (classic) email user base. Currently, most of these contacts use email clients with subject fields, and deltachat therefore has to find a way to communicate decently with all of them as well.

1 Like
38

BTW: The suggested chat-mode subject line format (chatting with peers using classic email clients) like
-[] Text... |
and
-[group name] Text... |

should be better than the curren Chat: Text..., because it is shorter, the symbols should work in any language, and the automatically but conditionally added, closing | allows deltachat to indicate that there is no need to download the whole email body, as there is no further text missing.

And together with always sending attachments in separate emails (to be downloaded only when desired), it also allows to mark those chat messages as containing no text, but only an attachment (-[] |). Making unnecessary, potentially expensive downloads optional.

The classic-mode subject line handling (for non-chat messages) would just resemble the behaviour of classic email clients.

39

A very obvious subject indication and naturally-feeling, manual editing mode:

40

I found Delta Chat a few days ago (google play v0.200) and love the idea. But I absolutely hate the subject munging. It completely breaks decades of e-mail precedent.

A major talking point is that we can use DC to chat with regular e-mail users. But…

  • the subject re-writing breaks Gmail conversations.
  • I can’t sort by subject. (I’m guessing gmail threads via subject)
  • there’s an endless “Chat:” -> “Re:” -> “Chat:” -> “Re:” loop

From my user standpoint, e-mails are grouped by subject (topic), not by members in the cc:. people get added, removed, it’s still the same subject. The subject finished, the same members may create a new topic. The old topic is archived.

Usage case: my friends and I are planning an outing. We don’t have identical chat. SMS sucks. Signal vs. whatsapp vs. facebook vs. etc. We all plan via long e-mail reply threads. This theoretically seems the ideal case for DeltaChat. But it’s not working. It’s broken on the email MUA since subjects are changed. It’s broken on DeltaChat since people get added and removed creating multiple groups/chats/conversations. It’s not working with people who use e-mail.

5 Likes
41

That’s a thing I also agree that should be considered. I feel like messing up the inbox of non-DC users.

42

For me it would be much more important to push "purge the delta chat folder from older messeges and reding notification mails:

Currently my mailbox space is wasted by “one line mails and reading notifications”.

I know the Delta Chat guys have started this.
But it seems they are a little bit fearful to delete wrong mails.

Still I think its really important.

1 Like
43

Hi, looks like you’re mainly talking about group chats.

In any case, there should be e.g. reference headers in the emails that should allow email clients to list the emails despite changing subjects, but maybe that is not enough for groups. Maybe the headers could need improving if it does not work for groups yet.

Support for the classic Re: scheme in the subject will be needed to support mailinglists anyway (https://github.com/deltachat/deltachat-core/issues/125), so that should become an option for chats (or even a state variable that is changeable by the contacts themselves?).

If deltachat creates a new group based on a new recipient that is added with a reply to a current group message, that is a clear bug. Please report. (Only a reply switching from a one-to-one chat message into a new group chat seems resaonable.)

I agree that it is unfortunate that there is no true archiving-and-closing of chats the moment. The existing “archived chats” feature is only a “hide chat from the recent chats list”.

44

I think K-9 follows the reference or in reply to, whereas gmail does not. Unfortunately, gmail is very popular and is a defacto standard. But once the mailinglist is implemented it should be ok. I’m glad it’s being worked on.

This doesn’t bother me too much from a clutter/UI perspective. I do share a bit of concern with the other topic about data storage usage.

I will keep an eye on this. I noticed this when I was pseudo-“importing” old emails to get a feel of the chat. I went into my e-mail archive, found an old (but active) conversation.

  • I marked the conversation thread unread.
  • I moved one email (oldest) into Inbox
  • waited for delta chat to pick it up
  • repeat one by one to build up the chat
  • (if I did it as a batch, they’d appear reverse order with newest first, didn’t experiment much)
  • (Oddly, ,this method may or may not work with e-mails I sent, only received)

Thats when I noticed that the chats whenever the CC: changed. I don’t know if anything else changed. I didn’t pay attention if there was a difference with recipients added or leaving, or if the reference header changed.

I’ll pay attention as I get new e-mails.

45

I only mentioned the archiving of entire chats, because it could allow working with thread or “topic wise” archiving as you described it, i.e. closing a chat without the next message in the same group automatically re-opening the old one, and appending to the formally archived chat (as it is now), but starting new empty chat (another conversation thread).

If you have two or three example messages of a group thread that create separate new chats in deltachat, these might serve well as a test case in a bug report, if you remove the personal data:
(https://github.com/deltachat/deltachat-core/issues)

46

I do. Subject in email - it is property of email communication, but chat.
I don’t have anything against idea to use DC as email client.
I just pointing out - not to mix chat with email in UI.
If DC would have separate tab where it can process email in usual way (subject, headers and etc) it would be a good addition, otherwise it hybrid email-o-chat.
Why not to keep things separately instead of creating spikes?

47

Im sorry, but CHAT isn’t the right tool to process EMAILs.
While DC using under the hood email technology, it is still called - the chat and should behave like a chat.

1 Like
48

Well, man-in-a-middle obviously would work in such scenarios, but there is still a choice to exchange keys manually to prevent it.

49

I absolutely agree :+1:

1 Like
50

that is just what we are talking about, we don’t want hybrid chat-email, but to have two view modes, chat and classic email, well as far as I had understood until now…

also CHAT doesn’t mess with your email INBOX, or have a battle to death with your classic MUA :wink:
becoming also the classic MUA is a way to win that war, otherwise people will stop using Delta Chat because it is messing it up with their classic MUA, but if Delta Chat is also a classic MUA people then understand “hey! I can’t use two email apps at the same time” then it will become more obvious.

51

so, why can’t we have a “two in one” app, maybe with the classic MUA view disabled by default, and always having the option to turn it on/off so if you just want just a “chat app” let it off, you have a chat app and us an email client from the future, everybody was happy forever and never used WhatsApp again, the end. :wink:

52

If DC will stop pretending to be a MUA, this war will ended. Any DC client(s) that first connected to IMAP, simply moving DC messages to DeltaChat folder and all other DC clients connected to that same account will simply pull new messages from DC folder.
My Thunderbird, Outlook, K9 never fight between each other when they connected to the same account. If one MUA moved message to a folder, it immediately reflected on all other clients. As of now, all people I know who using DC simply made dedicated email account to avoid mess between DC and regular emails, other simply stop using DC because of mess in INBOX.

DC messages mostly are pretty small and double downloading by email client and DC shouldn’t be an issue, so using dedicated for particular purpose apps IMHO is a way to stop this war.

53

As I said, if it would be two SEPARATE tabs, one for email messages and another one for DC messages, it might be useful for someone, but attempting to use email’s feature - subject in DC isn’t right way IMO.

Try to ask somebody to send you 40-50 kilobytes of plain text over DC and let us know, how comfortable you are to read such message in DC user interface on mobile device such as smartphone. It simply doesn’t fit logically to email messaging when one would try to read in portrait orientation on a half of screen long text.