Subject of 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 :slight_smile:

1 Like

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.

1 Like

Actually, I do not think that I would understand this :frowning_face:. 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.

When you’re viewing a chat, would it be possible to add a menu item, “Set Current Subject,” which causes every message you send to have a particular subject line? And then from now on in small text at the top of the screen, under the group name / recipient name, there would be a small bit of text saying, “Subject: [Whatever]”

That would make it so you can have a fully customizable subject, but still maintain an instant messenger-like feel.

I personally am not very interested in having a standard format that I can’t change. I would like fully customizable subject lines, if possible. This would allow me to be less self-conscious when sending quick messages to traditional email users.

1 Like

Sounds good.

These “chat topics” might even provide a way to fully represent a translateable concept of email subjects into chat views, instead of only allowing for some visualizing and editing in individual messages. The topics could allow to break a long list of intermingled messages down to a subject’s sub-tree of interest.

The subject or “topic” line that is shown at the the top of the screen, could not only allow to change the subject of the resulting email, but also to show a selection of subjects in the chat, that allows to filter out corresponding messages and reduce the view to the selected subject and its follow-ups.
This could very much ease the navigation in larger amounts of messages like on mailing lists (

I think this would be more complicated then the current messenger view.
A messenger should stay easy.
There is a logical grouped thread for every contact.
That’s the advantage of a messenger.

So I think it’s not a good idea to put things like this in the UI.

A messenger is a messenger and a Mail client is a Mail client.
This should not mixed to catch “non tech WhatsApp users”.

If you have developing skills you can fork DC an build a hybrid mail/chat client.
I think there are a few people who would like it.
But I’m sure more the 80% of the normal users want a simple to use (UI and UX) messenger.

1 Like

Yes, and I think the idea of “chats” is very good. The default would not, nor should, have to change.
(The Email-chat spec simply allows to correspond with any email address, thus also those using classic email subjects.)

Deltachat for itself would not impose a requirement to use subjects in its messages. But if some contact starts writing with different subjects (to stay on top of a larger bulk of messages) deltachat could just show the subject at the top of the chat (idea from pcrockett), and provide a filtering possibility (a search box, with the list of subjects already used in the chat, similar to “suggested search terms”), that gets shown by tapping on the title, whicht could have some “drop down” or “expand” icon to indicate this feature.

Showing the subject in the title also reduces the redundancy that would result from displaying subjects within every message.

As long as no customized subjects are used in a chat, everything could stay the same as it currently is. (Except the small indicator?)

One remaining question might be how to best allow deltachat users themself to do a first custom subject change. A tap on the title currently opens tabs for the group settings, gallery and documents, maybe that could just as well open with a new (to be introduced) tab for “subjects” or chat “topics”, containing a “plus” button for adding a custom subject.

I am not particularly interested in the subject in DC, but such insistence should be heard.

:page_facing_up:In the picture I show you how the matter looks in a normal SMS messaging application. If SMS messaging applications with chat view, support subject and nobody has complained about it, they will tell me, in an email application, where by nature it takes.

I do not think that takes away presence in the chat view, also only those who are very interested would use it. For those who do not interest him, he would remain hidden.

The subject is only important in communicating with an MUA and only in this case should it be allowed.

:mag_right: In SMS messaging applications, there are two ways to add subject:

  • From the menu with an option “add subject”
  • Or with a long press on the send button

And for the visualization, it seems good to me as it is in the image.


Muchas Gracias, I didn’t know that SMS supports subjects.

So, there actually is prior art for traditional subject support in a chat app. :slight_smile: And there is the possibility to optimize it to support email lists by showing the current top-subject only in the header, and provide a top-subject message filter (as pcrockett imagined above).


Not sure if anyone already mentioned this here, but Spike has addressed a similar issue already. Every time a user tries to compose a message, a pop-up appears with the current Email Subject, and you can either delete it or change it. A similar thing could be done here. Screenshot below:


Delta chat says, it has the widest community as it uses the traditional e-mail standard. I think this is only true if it is compatible to email and this means e-mail subjects need to be changeable. In my opinion this is highly important. I really don’t want to send my boss e-mails which start with “Chat:…” or “Group:…”

There have been some ideas how to manage this. For me, even a simple menu entry would make it. After changing the current subject, all following messages will be send with this subject.

I really love delta chat. Please think about implementing functionality like this.


DeltaChat is awesome, and it would be great to be able to configure the subject header!

The correct answer here is both of them.

  1. DC’s biggest feature is having no damn subject line. This is the main UX difference between “mail” and “chat”.
  2. But! Most DC users are using the application to talk with normies on traditional mail clients. And some DC users are always going to want more control over the result.

So surely the way forward is:

  1. Keep the Chat: ... feature as default behavior. Try to create a new standard. One day everyone may understand that Chat: ... means a message was sent with a simplified chat app, just as they understand what Re: ... and Fwd: ... mean.
  2. Provide a discreet opt-in setting for users who absolutely must edit their subject line.



we’ve just merged a pull-requests that targets the subject-things discussed here in this thread - thanks @all for contributing!) -

changes at a glance:

  • in group-chats, the subject is set to the group-name
  • the subject in one-to-one-chats is unchanged

it’s a simple rule now: group-name is the subject.

these changes allows Delta Chat users to send e-mails that look and behave like normal emails. the flow is nothing new: create group, set group-name, add members, send message.

a big advantage over extra controls or so (that i would really hate btw) is that the answers and subsequent messages get grouped together - in both, Delta Chat and in the traditional user agents. this won’t be easily the case when setting the subject per-message; things would probably just get more complex and harder to understand.

so, all in all, this does not change anything for pure Delta Chat users but offer a way to interact more nicely with traditional clients.


Why not have the client use an X-Header and-not subject?

1 Like

not sure what you are meaning.

this thread is mainly about what is visible to other mail programs, some hidden X-Header won’t help on that.


Did you mean to say “in lieu of subject header employ an X-header” ?

This seems the elegant solution as server and mail client can filter on this. DC would need UI for X-header management.