I think all your concerns can and need to be well incorporated in the right solution.
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.
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.