That’s a thing I also agree that should be considered. I feel like messing up the inbox of non-DC users.
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
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”.
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.
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)
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?
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
Well, man-in-a-middle obviously would work in such scenarios, but there is still a choice to exchange keys manually to prevent it.
I absolutely agree 
1 Like
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 
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.
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. 
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.
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.
But receiving is different from sending.
And being aware and in control of the subject, especially when sending a plain text messages to a new contact, has a value.
A very simple subject - indication that is intuitively editable is pretty informational and useful.
There no such thing as “subject” in chat applications. Email and chat are very distinct from each other.
It would be much more intuitively understandable if request to new contact would be send from different view(android) that replicate email interface, with a normal field for subject and message.
IMO, the view/page that now serve purpose for display “contact requests” is ideal place to turn it into standard email view. It would be clearly for everybody that this area is for unecrypted email messages.
If incoming message(s) doesn’t have field “X-Mailer: Delta Chat” in email header or there no “Autocrypt-Setup-Message:” field then route such messages to “contact request” view/page and display it as email message that contains subject and body of message.
Any attempts to extract from a message part of text that supposed to be encrypted simply breaking any cryptographics rules.
It is a leak ! You indirectly giving a clue about encrypted message.
Personally, I think that current implementation of autocrypt is insufficient. It must encrypt everything related to communication and leave in plain text email headers the only fields that need to satisfy MTA only, otherwise it calls - side channels in cryptography.
What you want from autocrypt may be a “strict” setting. (Different story.)
Deltachat only puts message textin the subject in cases when sending plain text messages, i.e. to a contact with which no established autocrypt connection exists. For example to contact someone not yet using deltachat.
But the same subject visualization can actually also serve to visualize the encryption state:
So I guess, no encrypted stuff is repeated in another channel.
You may check out that “memoryhole”, though. https://github.com/deltachat/deltachat-core/issues/70
your Thunderbird, Outlook, K9 never sent a self-bcc that makes an annoying notification from the others MUA pop up, and since we are talking about a chatting app, enjoy yourself having this notification every time you send a message, while actively chatting with a friend.
DC messages are quite big compared to equivalent messages sent with classic MUAs like K9 mail, and it is really important for some people like me that messages are not re-downloaded, a lot of people in my country expect to chat for 30 days with only 50MB of email traffic quota(each email have a cost), and for people that don’t have unlimited network, the notification for a message you send is confusing and annoying,
well since you seems to agree with a separated view for classic email I see no point keeping this discussion if we agree, also note we are talking about DC as a classic MUA which is in another post, lets keep talking only about subject here
have a nice day 
1 Like
This kind of behavior should please everybody. Do you want to take control of your mail? Add subject and stuff like that? You can do it by enabling this.
I don’t like this at all as a Delta Chat user and I urge the devs not to fragment the app in this way.
I want to write emails like chat to MUA users and have it be totally transparent on their side. I like that my subjects are formatted as the first few words of my email. It frees me from thinking about what it should say and provides good, glanceable context.
I want replies that are threaded and no Chat: prefix added. It is ugly and confusing to MUA users. I want all of this in a client that does not try and separate MUA users from Delta Chat users. It is a bridge between the worlds I appreciate and I hope the opinions of a few people loudly protesting do not drown out us other users.
2 Likes
@Oreyoter i hear you it’s an intricate topic. In any case, adding a “separate view/tab” with classic e-mail handling would be its own somewhat major sub-project and no dev (i know off) is going for it currently. FWIW, i also sympathize with exploring how much we can “bridge” worlds further than already works.