When replying to HTML emails, generate an HTML part that mimics the display the recipient would see were they using Delta Chat.
This would set the recipient in the mindset for writing a short chat style reply, and possibly even encourage them to investigate the program itself.
It could also include a message along the lines of:
This message was sent using Delta Chat (linked), please install it if you wish to reply using end to end encryption, otherwise reply normally and put 3 blank lines or one starting with 2 hyphens at the end of the message. And modify the client to recognise this accordingly.
that will be kind of unexpected, for context some nested quotes of old messages (the latest X messages from the thread) could be included, something that will be useful despite the email client supporting html or having it enabled. Also users don’t need to use Delta Chat to have e2e encrypted chat, Delta Chat is compatible with any autocrypt-capable client, like k9mail, etc.
This approach will consume more and more space on IMAP servers, because all previous messages must be included in the very latest mail (unless we scan for the previous ones and delete them periodically).
The next challenge: How to deal with expiring messages (if even possible)?
Honestly, no. I think it is far better to tell people to give Delta Chat a try.
That really misses the point. The unique massive strength of Delta Chat is that it is not limited to users of the program. My suggestion plays on this strength. Trying to convince someone to try an app that is complex to set up especially on multiple devices, when you are their only contact is an exercise in futility.
However, if what they see is similar to what they would see on iMessage or Telegram, it will automatically make them treat the message as an IM rather than an email, and should they start getting messages in that form from more than one contact, their interest will be piqued and they will ask you, about it.
I can’t see trying to fight other messengers which are superior in other respects, without playing to its unique strength is going to succeed.
I see DC as a compliment to other messengers, people use their favourite when possible, and then DC is there for everyone else. (I guess the ultimate would be dual clients with other open messengers.)
I cannot see any complexity in configuring Delta Chat. You just set up one client, enable “Send copy to self”, and do a backup. Then, you set up the next client, restore the backup, and enable “Send copy to self” in there as well. (By the way, any app that is difficult to configure will not be used by a majority of users. And the screenshots you would like to show do not tell people how easy/difficult it was to configure Delta Chat.)
Basically, you just enter username and password of your mail account. Sometimes additional settings have to be entered manually, e.g. hostnames/ports, security protocols etc., but that is the same with any other mail client.
Given the fact that the backbone of Delta Chat stll is Internet mail (for good reasons), the developers did a superb job. It all depends on how compliant to the specifications a mail provider is. Delta Chat supports (almost) all standards of automatic setup, and it works like a charm when the provider supports those standards, too. Things did not work out of the box in my case, because I am using an alias, but I had the same issue with Mozilla Thunderbird as well. (Which mail app should “know” that it is not possible to use an alias address as username to log in at Posteo?)
Telegram (and Whatsapp) is(/are) (a) native system(s): own servers, own clients, just the (Inter)net in between is not supplied from the developers. I agree that, under these conditions, things work out pretty straight forward, at least most of the time. On the other hand, I have to agree to terms and conditions if I want to use those services, but that is another story, of course…
That basically demonstrates my point. A difficult mainstream IM would be type in your phone number and then enter a a one time code, then your name.
And that is both a massive strength and an inherent weakness.
Focussing on saying the weaknesses aren’t too bad, and ignoring the strengths is not going help push the system.
The current messages look great on a plain text email system.
However we are in a tiny minority, the bulk of people don’t think HTML email is the spawn of Satan, (sadly). And it looks poor on that. So why not turn HTML into an advantage and give those users an attractive incoming message (for once)?
Delta Chat is a really neat idea, but that is only obvious to us geeks, to whom the config is also trivial.
It needs to appeal to ordinary people…
They get a message that looks like it’s from any text client, it is going to make no impression.
They get one that looks like a chat window, and is easy to reply to, it will make an impression.
Don’t forget, they will have been on the other end of what you are expecting them to send.
Your idea is good in theory, but will fail when it comes to execution:
Email quotas are a thing and the normal ones reach from 50MB-100MB until 2000MB, so if you already use your email account for some longer time and didn’t bother to delete old emails it will fill up really fast with html emails. (especially since those messenger messages are more common than you internet service/netflix/google/other html emails.)
People care about their data volume. While unlimited mobile data plans might be common in richer neighborhoods in the USA, even in Germany that is not the case yet. So sending/receiving such messages can eat up the data volume and then they rather use whatsapp or other messengers that preserve their data plan. (also some providers even offer free transfer of whatsapp/telegram/fb-messenger data packets - even if one could argue that is against net neutrality, it is still happening in some places, but that’s another topic.)
What you could do is a fork of deltachat that does this, but we can not put something like this in the main version of deltachat, because we have a broad community, not just people that have enough data volume to do this stuff.
Also additionally - you can not embed remote style sheets in all email clients, so styles have to be inline, which also will take up more space.
And email HTML is NOT regular HTML, instead it’s something weird where the market-shares of email clients dictates what features work and which don’t work. So for example the <table> element is still the standard way of arranging content in html emails, because it works nearly in all clients that are in use today.
Are you thinking of the Delta Chat user or the standard email user at the other end?
The former would run into the same problem with attachments, or even lots of plain text messages, and would surely be easily solved by expiry rules on DC?
The latter would be unlikely to run into an issue unless they had many contacts running DC, in which case installing DC would be the solution.
I have already made clear it should be configurable, on, off using mobile, off always.
Also it will make no difference to DC exchanges or those with plain text clients, because it only makes sense to send these in reply to a received regular HTML email in a chat. The initial message really wouldn’t see much benefit to chat style formatting.
Sure we can talk about how we could make this work, but I’m not convinced that this step is useful anytime soon, for the reasons I mentioned in my other posts.
Also making exceptions, like only send html emails to contacts with email clients or only in certain circumstances adds an amount of complexity and maintenance cost to the core which is huge in comparison to the benefit we could get from html emails.
Not to mention the logic to generate such html messages, it needs to convert all types of messages to html and we might add new message types in the future, also it would need to have tests.
DeltaChat is opensource so you could make a fork and try it out (or try to convince someone to do so if you don’t feel ready to hack around in the rust core source code), but trust me its a bit too much work for the benefit you get.
If you have to decide on a new feature you should always look at:
Future maintenance cost (updating the code and tests in the future to make sure they will still work in the future)
Possible negative side-effects (such as increased message size, which may lead to negative feedback)
Possible Benefits (is the benefit enough to justify the cost)
Cost can be time or paying someone for their time, so it could be also money.
PS: who knows, maybe a prototype could convince some of the core-devs to implement such a thing, but as we’re currently busy with other things such as email-compat (mailinglists, show html emails, ui for it and so on) I wouldn’t have too high hopes on this specific idea.
You know normal people, they are easily agitated and always blame their problems on the new thing.
So if their email provider is bad, they blame it on DeltaChat.
Offtopic: Though somehow apple users often blame themselves instead of apple, I wonder how they got their users to think that way…
For the reasons I gave elsewhere, not doing this will limit delta chat to techies. If you wish to keep this excellent idea of using email as a IM transport a minority system, they please dismiss this idea. Delta Chat has too many limitations, to ignore its massive advantage that no other IM has, and expect it to catch on.
And that is the interoperability with email. If regular mail users don’t see it as chat, they use it as email. And it’s really not much good like that.
And if they see it as chat, they’ll ask (especially once they have a couple of contacts using), how can I sent messages that look like this?
Then you have new users.
The only use case I personally have is when I’m out with people with mobile phones with email and no Telegram or Viber. I think the system is worth more than that, and this suggestion attempts to make it so.
I have tried using it initiate chats, to friends with regular mailclients. (They won’t install new IMs) they never become chats and fizzle out, presumably because I’m doing short replies to their long emails.
Presenting their incoming message as though it were the last 3 or 4 messages in iMessage for example, should solve that.