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 
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.
@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.
What do you think of the “bridge” idea to only implicitly visualize the resulting subject in the text editor (for sending, similar as in received messages) with a hyphen - like in below examples?
Do you still see any intricates?
The subject may look (be marked) the same way as in received messages, i.e. ending with a - but additionally with a grey background.
For regular chat messages, the written text in the editor could be prepended with a lock that indicates that the message is going to get encrypted.
🔒- Written text…(Here the background and - hints to the canonical subject being used in the resulting autocrypted email.)
But in cases that an unencrypted email is going to be sent, the entered text would first be part of the subject and thus written with the grey background.
🔓 Written text... up to max subject length - further written text.Entering a new line within in the “subject length” could manually end the subject, at any time, allowing to thoughtfully choose and write a subject (if desired).
The marking in the editor might even be with only the - at the end (without a gray background), to be less noticeable, but still visible. However, I think writting the text starting with a grey background would also provide more attention to when the message is going to be sent as plain-text, which is a nice effect.
My only concern is the subject changing at every new message. A fixed subject or a subject that lasted, let’s saysay 24h, would be good enough to keep the destination box organized.
Yes, “subject keeping” is a good point. And it would also be a requirement for Reply to Message and mailing list support.
So how could the classic subject handling be integrated nicely in the UI?
Idea:
🔓 Re: The current subject-, and the cursor already positioned behind it.And concerning your aspect of message threading errors at some contacts’ clients (email client that only sorts by subject text but not based on headers):
As it can not be expected that contacts switch to another email client very quickly: Either a per chat or per contact setting, or even better shipping with a list of affected email clients and automatically using the “subject keeping” if a recipient uses such an email client.
I like current logic. Chat prefix gives new people the idea that you are in chat-mode with them and you expect a quick answer right now, not a lengthy tomorrow.
And beginning of the message in subj let people reply via ordinary clients faster (espesially using mobile apps): they starting to read you starting from notification.
When the message is encrypted it doesn’t leak to subj.
Everything is perfect! )
Why not to archive DeltaChat folder once in a while?? Sounds pretty simple.
Then your other MUA users have to use the same software to be able to call it the “Chat”
Then you simply use normal MUA to communicate with other MUA.
Chat isn’t normal full blown email.
Why are you using the chat application, if you’d like functionality of email client?
If you are saying “my email”, it means you have to use email, not a chat. Just forget that DeltaChat is using email transport under the hood.
What do you want to do with DeltaChat with such proposals - it won’t be neither Chat, nor normal eMail client.
Chat messages are generally short and don’t have “subject” properties. It abnormal for chat message to have “subject” for such type of applications. Chat applications don’t exhibit email properties such as threaded conversation. Mixing features you want, simply making DeltaChat to became DeltaEmail.
I really can’t get it, why not already use bunch of existing tools that behave as you liked (email clients aka MUA) instead of attempting to convert chat app to some kinda of hybrid monster.
Could you please explain, why ???
Personally, it is because I like the chat-like interface a lot more:
…and I am not using a chat client because I want to make use of Delta Chat’s most important feature: Compability to emails.
add to that that it is easier to share pictures and other media, and to record audio and now video, also the media compression stuff is important to me.
But just to be fair, some aspects you mention are possible in a classic email app like k9 mail, for example, I am testing the UX of an user using k9 to chat with delta chat users, and after some tweaks it is not that bad, for example you can enable the thread view which will group messages by dc chats, you can disable the option to save the messages you sent in the Sent folder and use the option to set a bcc address to send a copy of your messages to yourself that is what Delta Chat does, and your own messages will be shown in the threads, you can customize the number of lines of email preview in the email list to 6, so for short chat messages you don’t have to open the email,
this is the closest to a Delta Chat app I could get with k9, and it is not that bad, honestly I was expecting to be a hassle to chat with a Delta Chat user using a classic email app but it was not the case 
I think there is about no point in trying to convince “to subject or not”. The case has quite clear conditions.
Re: ... messages are required for mailing lists. But once implemented, the same visualization can also be very useful for direct in-reply-to answers in group chats: Referencing the original message even if just by showing a clickable default link “Re: First few words…”.
Otherwise, for chats, the subject is only relevant when sending non-encrypted messages, but this can still be integrated seamlessly and nicely.
The subject can be visualized and written in the editor completely unobtrusively for unencrypted messages, for example, with a slightly darker background. Together with visualizing the encryption state it may go like this:
🔓 When writing an unencrypted message, the text written until the max. subject length is then shown with a darker background while the typing can just go on normally beyond that. The resulting subject of the unencrypted message is then easily visible, and understood without requiring reading of documentation. And after seeing it in action when communicating with plain-email contacts, it will also become useful (for those who care) that the subject is easy to control:
🔓 A shorter subject
is very easy to “define” with this visualization scheme, if wanted, just by starting a new line before reaching the max. length of the subject.
Actually, I do not think that I would understand this 
. Also, it would annoy me.
Well, don’t you think you already understood it? And think it would annoy you?
OK, but why is that so?
Please remember that you would only see the slightly darker background, when writing to a classic email contact, where the handling of the subject really makes a difference.
Consider how annoying it can be to classic-email contacts…
Consider how annoying it can be to classic-email contacts, to read always self-repeating messages from deltachat people, that don’t see the emails they send out.
I understood it because you explained, it, but I would not understand it without documentation.
By the way, would you idea mean that the chat: prefix is added?
When we first touched the Chat: prefix in this thread (proposing this for the mixed-environment:)
the thought was about making the default deltachat prefix short and to find a way to mention the group or topic for the email recipients. And -[] could be a short, language independent “chat prefix” ( possibly even seen as symbolizing a text bubble). It could hold the short group name for group messages, and a closing | could indicate to the recipients that there is no more text in the body to look for.
I think a short chat prefix is nice to indicate the “chat mode”, it would only have to be omitted for classic Re: replies to mailing list messages and maybe messages that clearly classify as emails.
Maybe we can still find a better idea to visualize, and to allow specifying the subject (for Re: replies and classic chat-thread starting messages) for good measure at classic email client contacts.
What do you think?:
One point I noticed now is that the visualization in the editor would only be necessary for non-chat messages after the text gets longer and does not fit entirely into the subject field anymore. Do you think only visualizing the subject part then could reduce the annoyance you see, and resemble more closely the “problem / issue” or the way that the recipient sees the message?
🔓Using bold text to indicate the subject in longer messages
would also be possible and might come more naturally, since headings are frequently seen in bold letters.