The landing page may be a bit too minimal in giving overview of this cool project. I really liked the direction towards real-time P2P networking, based on Iroh [0]. See the blog post about this [1].
> After almost two years of collaboration with the wonderful Iroh team, and years of discussions with numerous experts in the decentralization space, we are happy to announce that Delta Chat 1.48 apps on all platforms contain state-of-the-art Peer-to-Peer networking support, including hole punching and forward-secret end-to-end encryption. Concretely, Delta Chat now establishes private Peer-to-Peer gossipping networks between users who start a webxdc app that uses the new joinRealtimeChannel() API.
I’ve been experimenting with Iroh over the past month. It’s been such a pleasant experience. Previously, I created a p2p connection with webrtc and had to create a layer on top of that to use request/response style communication between nodes. I can throw that all away with Iroh and focus on the product. It’s a relief.
In a sensible world, we would be using this, instead of whatsapp. It is amazing that even really a vast majority of, even technical people, not once stopped and looked at whatsapp, and said "Wait, e-mail can do this, we just need a pretty UI".
>It is amazing that even really a vast majority of, even technical people, not once stopped and looked at whatsapp, and said "Wait, e-mail can do this, we just need a pretty UI".
WhatsApp lets people find each other with phone numbers instead email addresses. This has a profound difference in real-world usability because it decreases friction.
Before WhatsApp, people texted each other using cell companies' SMS service.
Why did Person A (who already had an email address) send a SMS text to Person B (who also already had an email address) to chat?!? Because both people already had each others' phone number in their smartphone's address books. Recording each other's email address is less likely so it won't be used as "ids" to chat -- especially between friends & family.
To wit, my mother has already memorized my brand new phone number that I've only had for a few years but she doesn't know my email address at all even though I've sent it and re-sent it to her multiple times. To normal people, the phone numbers are more sacred than email addresses. WhatsApp was a continuation of the conveniences of SMS -- without paying 10 cents per message to the mobile phone carriers.
Friction from cognitive overhead is a big deal in technology adoption.
> Why did Person A (who already had an email address) send a SMS text to Person B (who also already had an email address) to chat?!?
Arguably primarily because they want to chat with them and not email them. The two have vastly different UX beyond just contact discovery.
Before WhatsApp there were ICQ (also number-based!), MSN, Skype... WhatsApp's main contribution over these was indeed using phone numbers and contacts access for automated contact discovery, but I don't think it makes sense at all to characterize it as a usability improvement on email.
Another case in point: iMessage supports email addresses as identifiers too. I don't even have my phone number on there because I consider it a strictly inferior identifier (it changes every time I move countries, I lose it if payments to my operator ever lapse, unlike a TLD I have no way of owning it independently from a phone plan etc.)
>but I don't think it makes sense at all to characterize it as a usability improvement on email.
Chats in general (not WhatsApp specifically) have "better" usability than email for some people because:
+ chats skipp the extra keystrokes of email workflow such as "Compose new email" and then enter an extra "Subject:" line which makes normal people put useless things in there such as "a quick question..." and then put the real conversation in the email body. It's a bunch of extra friction for no reason when communicating informally between friends & family.
+ chat ids such as phone numbers are not given out as freely as email addresses which makes chats have less spam and clutter and more easily isolated to personal communications. Email inboxes are clogged up with a bunch of non-chat mails like shipment notifications from Amazon.
I actually prefer email comms and have told my family to send me emails instead of text chats because I'm always at my desk and can use my full keyboard to type out a reply -- but -- they ignore me and always just send text chats. Normal people have a mental model that's geared toward text chats.
E.g. I saw my aunt again 30 years after she last saw me and one of the first things she asked was "What's your phone #? I want to send you a photo when you were little." And because I received her text, I now have my aunt's phone # in my Contacts app. But I don't have her email address. She never gave it to me; and I never asked for it.
Exchanging phone #s is the natural thing to do between friends & family. On the other hand, exchanging emails is often more natural when interacting in business settings or dealing with people at arms length.
Email address is a *far* better identifier than a random string of numbers though. The only reason why phone number discoverability works better is because everyone keeps being in that ancient world.
>both people already had each others' phone number in their smartphone's address book...
Look if it is saved in the smartphone's address book, why does it matter if it is email or a phone number. I bet that people don't actually memorize even the phone numbers of people close to them these days.
>Why did Person A (who already had an email address) send a SMS text to Person B (who also already had an email address) to chat?!?
I think it is because we didn't have near universal internet access in smartphones for a long time. If Whatsapp (or something like that) was a little bit late to appear, and the tech crowd was actually a bit more smarter, things like Delta Chat had a much better chance to be in Whatsapps current place.
>Look if it is saved in the smartphone's address book, why does it matter if it is email or a phone number.
Because when people interact with each other in informal situations, it's the phone numbers that are shared. Not email addresses. Thus, email addresses are often not in the Contacts app at all.
That ship seems to have largely sailed and the trend will be hard to reverse given how cell number has started to become all-purpose ID number tracker.
To say nothing of the fact that most people are not running their own email servers so that messaging is going to reside in places they don't own and the fact that relays get to read about everything exacerbating that problem, so you cannot really expect forward secrecy:
Does this solve all the other problems with encrypted email, which is not widely used for a reason?
messaging is going to reside in places they don't own
but that is the case with every messenger that stores messages on your behalf. telegram, whatsapp, signal... with those ALL people are not running their own servers.
whatsapp and signal store encrypted copies of the messages, and so does deltachat.
beyond that each client also stores a copy of each message locally. as does deltachat.
in difference to all others at least with deltachat i have a choice to use a different server that i trust. with whatsapp and signal i don't have that choice.
> most people are not running their own email servers
I honestly don't care about what the people I communicate with do, as long as I have the capability to at least own my persistent identifier (i.e. my TLD).
Just having that capability exerts just the right type of pressure on large service providers to maintain a baseline quality of service, regardless of whether the majority actually makes use of it or not, just like phone number portability has done in that domain.
Does this solve all the other problems with encrypted email
it doesn't solve all of them but a few at least. i don't believe using pgp itself is a problem. if it was deltachat could replace it with another better encryption.
metadata is a problem. that could be solved by removing messages from the email server and storing them elsewhere. (or storing them back on the server with the metadata removed). that doesn't prevent intermediate mail forwarders from keeping a copy though.
i think that is the real problem. deltachat doesn't control the communication channel and can't prevent leaking. i don't know how matrix or jabber compare here. if they use intermediate servers to forward messages the problem would remain.
message content leaking is not a problem because messages won't ever be decrypted on the server.
long term secret leaking is a problem tied to the current implementation of pgp. deltachat could change that (and maybe it does?)
Email is the completely wrong protocol choice for instant messaging. It's just a completely different use case. You wouldn't send a letter to the fire department if your house is on fire either.
When you use XMPP or Matrix you know your message will be delivered instantly. When you use email you don't. But that's only because we haven't defined an extension that tells the client whether the server can deliver messages instantly. It's not really that inherent to the system. Surely you've had at least one real-time conversation by email because both of you happened to be online at the same time and nothing went wrong necessitating a message delay.
Yes, it's theoretically possible to adapt many protocols to many use cases, but that doesn't mean it's a good idea. Email and XMPP are just geared towards very different use cases.
In particular, Email has a lot of assumptions about acceptable delivery delays, bidirectional (non-)reachability etc. baked in that would be very hard to globally undo.
As programmers, is it not our natural instinct to create a ChatSystem and MailSystem on top of a GenericMessageDeliverySystem? When did we stop doing that? Creating a brand new GenericMessageDeliverySystem for each purpose comes with substantial costs. We don't reinvent the Internet to create WhatsApp.
I think the point is that it builds on existing infrastructure that almost everyone already has in their life. Whether you self-host, use a niche provider, or a mainstream provider, email provides a pretty interoperable starting point which isn't a walled garden and doesn't have to be owned by FAANG.
Are there some compromises? Of course. But creating new accounts, or using new services isn't one of them. Email-speed instant messaging is good enough for me.
And to be honest, as much as I like Matrix, it has plenty of compromise of its own - including speed/reliability when using their own servers.
Email is a communication system with a lot of moving parts. You can't have reliable IM through existing MX servers but you may have it if for example SMTPs are running on your machine and you poll their data more (it's just an example, I know that with an SMTP running on your phone you'd have more problems).
See earlier on today's front page, another all in one mail server. It is much, much simpler than it was to do this. I've been self hosting email for nearly 20 years and the state of the art is considerably better now. Latency is virtually nonexistent and federation works.
I mean... WhatsApp is literally XMPP / Jabber... It's amazing that we didn't stop and said, wait, Jabber can do this, we just need a pretty UI...
Hell, Jabber can still do this. I'm not convinced of the other modern alternatives that don't have half the functional capabilities that Jabber do.
The only "downside" of Jabber is that it's XML based, but really if you think about it, that's a strength. Anyone here could probably parse the protocol effortlessly. There's also lots of fully functional clients out today, and servers that scale like nobody's business.
I'm more ashamed we don't invest more into XMPP: Google Talk, Facebook Chat and WhatsApp were built around it. These are companies with insane to scale userbases, tried and tested.
Here's a 2008 article from Facebook on using their chat with a Jabber client:
> it's XML based, but really if you think about it, that's a strength
Nope.
Another downside is the X. The protocol being extensible means that no two clients implement the same subset of extensions making it useless. I’ve been scolded in the past for using the "wrong" client, making my messages look weird for people using the "right" client. Just make a good protocol.
Even though I am part of this secure messaging group chat on matrix thing and I had even created a whole tierlist of security of protocols etc. and saw delta chat & have it running and fiddled with it.
The fact that it is written by creator of pypy is wholesome!!
On the positive side, the use of P2P and IMAP makes censorship difficult, which is a strong advantage in authoritarian regimes.
However this comes with serious trade-offs. PGP lacks forward secrecy: if a key leaks, all past messages can be decrypted. Also IMAP offers no metadata privacy, anyone can see who you email and how often.
> Signal and WhatsApp are likely a step ahead in terms of privacy
WhatsApp is closed source, so whatever they claim to can't be proven. And remember that both WhatsApp and Signal are legally required not to disclose to you whether they are spying on you or not.
> WhatsApp is closed source, so whatever they claim to can't be proven
E2E only requires a correctly-designed client, not a correctly-designed server.
Since any binary can always be deobfuscated, deliberately putting in a backdoor in the client would be an extremely risky PR move, especially in an app as big as WhatsApp, and one surely receiving lots of attention from security researchers.
Not to mention that OpenWhisperSystems (the creators of Signal) worked with Meta on their E2E implementation, and if you don't trust them to do right, you shouldn't trust anybody.
Let's face it, people over here just don't like Meta and love to spread FUD about them.
One trust is lost, it's hard to regain it. The fact is, the WhatsApp client is not open source, there are no reproducible builds, and only thing you have is trust in them.
If you live in an authoritarian state with a track record of spying on individual citizens, and without legal protection for the privacy of foreign citizens, it's legitimate to decide not to trust a company like Meta headquartered in the USA.
> The fact is, the WhatsApp client is not open source, there are no reproducible builds, and only thing you have is trust in them.
That is not strictly true. It is possible to reverse-engineer the client. It's unlikely that anyone will find the motivation to do so, but there's no law of physics that says they can't. You can theoretically review the code that is running on your device - it's just harder than with an open source reproducible build.
What would be the consequences, if Meta was caught doing something "funny" with e2ee? Maybe small fines, and a brief online moral panic, but I don't think people would switch to another app en masse solely because of that.
I love this optimism, I really do. But to believe that any meta product can be private is to believe that Zuck actually wants that to happen. Zuck, the guy who changes company culture every 4 years or less to suit whoever is on the white house. The reality is that with a closed source product, you can't trust ANYTHING. Just because OpenWhisperSystems worked with Meta doesn't mean anything. Meta will easily silence them legally if they wanted to. And Meta can always remove or disable the implementation as they see fit.
Are you talking about decompilation? This, is in general very difficult, and that's when the author and compiler don't want to stop you from doing it.
Go fire up jadx or ghidra or whatever you like and see if you can find the bits of code you know are there. Now try demonstrating that a bit of code isn't there.
>Let's face it, people over here just don't like Meta and love to spread FUD about them.
It's called punching upwards.
>Since any binary can always be deobfuscated, deliberately putting in a backdoor in the client would be an extremely risky PR move, especially in an app as big as WhatsApp, and one surely receiving lots of attention from security researchers
Correct me if I'm wrong, but can't a proprietary delivery mechanism such as the App or Play stores deliver a backdoored build to an individual device, then later autoupdate it to a clean one?
Builds are signed by the software publisher, not the Play Store. So the store alone couldn't corrupt releases, it would need collaboration by the publisher. (Google does have a service for app developers where they keep and manage your signing keys for you, but it's not required)
WhatsApp obviously cannot be trusted for message privacy for the simple reason that Meta paid gazillion bucks for it. I don't understand why people need more evidence beyond that.
If your device is confiscated your entire history is in the clear. Forward secrecy doesn't magically solve problems, it's useful if you use ephemeral messages. In DC if there's a window of time where you want messages to not be traceable you just create a new email adress (which is just one click in DC thanks to chatmail) and delete that address after, that's it.
> if a key leaks, all past messages can be decrypted
Not to mention, if you revoke a key (maybe because you lost your laptop and want to be proactive about security), without any authenticated timestamping service in the mix, all past messages and signatures can no longer be trusted, regardless of the revocation date. That's why when you revoke a key on github, all your previous commits' signatures turn red.
I've never understood why no one's succeeded in doing anything about this after all these years.
forward secrecy seems to apply to realtime connections, not to messages sent over SMTP.
now what's interesting here is a potential future development of deltachat where SMTP is only used to negotiate the peer to peer connection, and the actual chat messages are sent over the direct connection. although it sounds kind of weird to build a chat solution on top of SMTP and then bypass SMTP in the end.
the remaining benefit would be the ability to talk to people who don't use deltachat. not needing another account on a new service. not needing to develop or maintain server infrastructure.
Several years ago I tried DeltaChat and it caused an insurmountable problem: my mail provider kept locking me out of my account. Almost certainly it was because DeltaChat's suspiciously ciphertext-filled messages were triggering the abuse lockdown.
The provider was GMX and it was their fault, not DeltaChat's. But I had to call off the experiment.
The most important factor with email, is that your inbox is encrypted at rest at all times... and cannot be bruteforced.
The chances of your email messages being 'man in the middled' are almost non-existent. Its a micro-percent of live investigations that does this.
The police RELY ON finding messages in either your inbox or the recipients. It doesnt matter if they are encrypted or not in reality. Of course they'd like to read them and if they are this deep into you. Its likely they still will (probably from the recipients lesser password hygiene than yours).
Almost no evidence is every 'plucked' out of the air and read. It just doesnt work that way.
However, software like Delta is better than nothing esp for normies. Its just limited in use for people who really need ways to frustrate LE.
Source: Ive been under NCA and FBI investigation before. Protonmail with the two password method stopped them every time. Memorise the 2nd password and password manager the first.
> Ive been under NCA and FBI investigation before. Protonmail with the two password method stopped them every time. Memorise the 2nd password and password manager the first.
Unless you exclusively use proton-bridge and disabled auto-update, then proton controls all endpoints in which your passwords live.
So what is preventing the FBI from forcing Proton to serve a special UI just to you that will be used to exfiltrate your second password?
I wish I could send a one-time link to my father where we could play chess against each other by re-visiting the same link.
The e-mail part made me think of this. I have no use for an e-mail based chat but an online chess game that's easy to use without registration would be cool. He's 82 and he can't use complex sites.
well then deltachat is exactly what you want because it supports webxdc apps which can run in the deltachat client. here is the chess app: https://webxdc.org/apps/#arcanecircle-chess
The whole purpose of using a distributed IM like Delta Chat is to break free from big data leeches like Google. If you're just using Delta Chat with a centralized Gmail server as the backend, doesn’t that defeat the point?
at one point that used to be how email worked too. for me the point of using deltachat is that it works with my existing service and that it does not depend on any particular company/service. issues with google are secondary. deltachat is still useful even with gmail.
I tried to use it, liked the concept, but the way it handles email is a mess, making it unusable for my use case of trying to use it as an alternative mail client for my normal mail account.
The issue is, if an email is sent to one of my aliases, instead of seeing one conversation between the sender and a recipient (my alias) every message creates a new group chat with the sender, my main account and my alias as members. For every single mail, even when all members are the same, a new group is created. When I reply in that group, then the email will be sent to all group members, including the original sender, and my alias. And sender would always be the main account.
This is a known Delta chat issue, but they deem it too niche to consider properly supporting aliases.
In an ideal world, when an email arrives, it should create a conversation between a sender and a recipient (alias) without adding a main account as a member. Sending a new message in that conversation will automatically use an alias as a sender. For new chats/conversations, I should be able to choose which alias to use.
Then I would be able to use it as a chat UI for my mail messages.
a long time ago i envisioned that mail clients should really display mails as a conversation just like you describe. a list with all my contacts. and opening the contact gives me all emails received and sent with that contact.
if you want to use different aliases in deltachat, i think the best option for now is to create different deltachat profiles for each. you can have multiple profiles active at once and you get notifications for all of them, you only have to switch profiles to see all the messages. switching profiles is a single click and feels like switching folders in traditional mail clients.
Yes, but the issue is they all share the same inbox, and my email server doesn't support server-side incoming filters so I can distribute mails to separate inbox folders that would be monitored by DeltaChat.
Alias is a standard email feature. If Delta Chat want's to be usable as a general mail client, aliases should just work.
would be nice if all the "no, no, this can't work! email is slow! blah blah" guys once and for all actually give it a try to the app and realize IT WORKS AND IT IS BLAZING FAST! I have been using it since years with my family and some friends without any problems, it is the best I could find after trying Matrix, XMPP, etc.
Ah the famously friendly UX of PGP combined with the solid reliability of email. This is trying to get two drunks to stand up straight by leaning them against each other.
They've actually cracked PGP, and email is fine, especially between self hosters and anyone using chatmail. I've been using it for years: Delta really, really works.
PGP has been cracked when you use it with automation in that you can steal keys slowly by relying on the meta-behavior of systems around PGP. A classic attack here is timing how long it takes for a PGP-based automated system to reject your messages.
PGP is intended for the classic "used by a human to encrypt emails manually" flow and is actually insecure if you automate around it.
the timing attack you're describing is extremely common -- not unique to PGP -- and simple to mitigate. do you have more literature about the attack, or attacks, that you're describing?
The landing page may be a bit too minimal in giving overview of this cool project. I really liked the direction towards real-time P2P networking, based on Iroh [0]. See the blog post about this [1].
> After almost two years of collaboration with the wonderful Iroh team, and years of discussions with numerous experts in the decentralization space, we are happy to announce that Delta Chat 1.48 apps on all platforms contain state-of-the-art Peer-to-Peer networking support, including hole punching and forward-secret end-to-end encryption. Concretely, Delta Chat now establishes private Peer-to-Peer gossipping networks between users who start a webxdc app that uses the new joinRealtimeChannel() API.
[0] https://iroh.computer/
[1] https://delta.chat/en/2024-11-20-webxdc-realtime
I’ve been experimenting with Iroh over the past month. It’s been such a pleasant experience. Previously, I created a p2p connection with webrtc and had to create a layer on top of that to use request/response style communication between nodes. I can throw that all away with Iroh and focus on the product. It’s a relief.
There was a few talks about Delta Chat in FOSDEM'25. Seems it has come a long way since inception.
https://fosdem.org/2025/schedule/event/fosdem-2025-5853-delt...
https://fosdem.org/2025/schedule/event/fosdem-2025-5217-chat...
In a sensible world, we would be using this, instead of whatsapp. It is amazing that even really a vast majority of, even technical people, not once stopped and looked at whatsapp, and said "Wait, e-mail can do this, we just need a pretty UI".
>It is amazing that even really a vast majority of, even technical people, not once stopped and looked at whatsapp, and said "Wait, e-mail can do this, we just need a pretty UI".
WhatsApp lets people find each other with phone numbers instead email addresses. This has a profound difference in real-world usability because it decreases friction.
Before WhatsApp, people texted each other using cell companies' SMS service.
Why did Person A (who already had an email address) send a SMS text to Person B (who also already had an email address) to chat?!? Because both people already had each others' phone number in their smartphone's address books. Recording each other's email address is less likely so it won't be used as "ids" to chat -- especially between friends & family.
To wit, my mother has already memorized my brand new phone number that I've only had for a few years but she doesn't know my email address at all even though I've sent it and re-sent it to her multiple times. To normal people, the phone numbers are more sacred than email addresses. WhatsApp was a continuation of the conveniences of SMS -- without paying 10 cents per message to the mobile phone carriers.
Friction from cognitive overhead is a big deal in technology adoption.
> Why did Person A (who already had an email address) send a SMS text to Person B (who also already had an email address) to chat?!?
Arguably primarily because they want to chat with them and not email them. The two have vastly different UX beyond just contact discovery.
Before WhatsApp there were ICQ (also number-based!), MSN, Skype... WhatsApp's main contribution over these was indeed using phone numbers and contacts access for automated contact discovery, but I don't think it makes sense at all to characterize it as a usability improvement on email.
Another case in point: iMessage supports email addresses as identifiers too. I don't even have my phone number on there because I consider it a strictly inferior identifier (it changes every time I move countries, I lose it if payments to my operator ever lapse, unlike a TLD I have no way of owning it independently from a phone plan etc.)
>but I don't think it makes sense at all to characterize it as a usability improvement on email.
Chats in general (not WhatsApp specifically) have "better" usability than email for some people because:
+ chats skipp the extra keystrokes of email workflow such as "Compose new email" and then enter an extra "Subject:" line which makes normal people put useless things in there such as "a quick question..." and then put the real conversation in the email body. It's a bunch of extra friction for no reason when communicating informally between friends & family.
+ chat ids such as phone numbers are not given out as freely as email addresses which makes chats have less spam and clutter and more easily isolated to personal communications. Email inboxes are clogged up with a bunch of non-chat mails like shipment notifications from Amazon.
I actually prefer email comms and have told my family to send me emails instead of text chats because I'm always at my desk and can use my full keyboard to type out a reply -- but -- they ignore me and always just send text chats. Normal people have a mental model that's geared toward text chats.
E.g. I saw my aunt again 30 years after she last saw me and one of the first things she asked was "What's your phone #? I want to send you a photo when you were little." And because I received her text, I now have my aunt's phone # in my Contacts app. But I don't have her email address. She never gave it to me; and I never asked for it.
Exchanging phone #s is the natural thing to do between friends & family. On the other hand, exchanging emails is often more natural when interacting in business settings or dealing with people at arms length.
> Chats in general (not WhatsApp specifically) have "better" usability than email
Definitely, but that's not WhatsApp's innovation.
just give them your signal number and use signal desktop
i do the same as you as i dont carry a phone anymore (fucking with the police).
Email address is a *far* better identifier than a random string of numbers though. The only reason why phone number discoverability works better is because everyone keeps being in that ancient world.
>both people already had each others' phone number in their smartphone's address book...
Look if it is saved in the smartphone's address book, why does it matter if it is email or a phone number. I bet that people don't actually memorize even the phone numbers of people close to them these days.
>Why did Person A (who already had an email address) send a SMS text to Person B (who also already had an email address) to chat?!?
I think it is because we didn't have near universal internet access in smartphones for a long time. If Whatsapp (or something like that) was a little bit late to appear, and the tech crowd was actually a bit more smarter, things like Delta Chat had a much better chance to be in Whatsapps current place.
>Look if it is saved in the smartphone's address book, why does it matter if it is email or a phone number.
Because when people interact with each other in informal situations, it's the phone numbers that are shared. Not email addresses. Thus, email addresses are often not in the Contacts app at all.
I mean you could simply setup a registry of Aliases for emails to achieve the same effect?
On the same note, isn't phone numbers being more sensitive information than email nowadays, hence you might not want to share it.
That ship seems to have largely sailed and the trend will be hard to reverse given how cell number has started to become all-purpose ID number tracker.
To say nothing of the fact that most people are not running their own email servers so that messaging is going to reside in places they don't own and the fact that relays get to read about everything exacerbating that problem, so you cannot really expect forward secrecy:
Does this solve all the other problems with encrypted email, which is not widely used for a reason?
Here's a discussion
https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...
messaging is going to reside in places they don't own
but that is the case with every messenger that stores messages on your behalf. telegram, whatsapp, signal... with those ALL people are not running their own servers.
whatsapp and signal store encrypted copies of the messages, and so does deltachat.
beyond that each client also stores a copy of each message locally. as does deltachat.
in difference to all others at least with deltachat i have a choice to use a different server that i trust. with whatsapp and signal i don't have that choice.
> most people are not running their own email servers
I honestly don't care about what the people I communicate with do, as long as I have the capability to at least own my persistent identifier (i.e. my TLD).
Just having that capability exerts just the right type of pressure on large service providers to maintain a baseline quality of service, regardless of whether the majority actually makes use of it or not, just like phone number portability has done in that domain.
Does this solve all the other problems with encrypted email
it doesn't solve all of them but a few at least. i don't believe using pgp itself is a problem. if it was deltachat could replace it with another better encryption.
metadata is a problem. that could be solved by removing messages from the email server and storing them elsewhere. (or storing them back on the server with the metadata removed). that doesn't prevent intermediate mail forwarders from keeping a copy though. i think that is the real problem. deltachat doesn't control the communication channel and can't prevent leaking. i don't know how matrix or jabber compare here. if they use intermediate servers to forward messages the problem would remain.
message content leaking is not a problem because messages won't ever be decrypted on the server.
long term secret leaking is a problem tied to the current implementation of pgp. deltachat could change that (and maybe it does?)
No, if anything we'd be using XMPP or Matrix.
Email is the completely wrong protocol choice for instant messaging. It's just a completely different use case. You wouldn't send a letter to the fire department if your house is on fire either.
Only because we choose it to be.
When you use XMPP or Matrix you know your message will be delivered instantly. When you use email you don't. But that's only because we haven't defined an extension that tells the client whether the server can deliver messages instantly. It's not really that inherent to the system. Surely you've had at least one real-time conversation by email because both of you happened to be online at the same time and nothing went wrong necessitating a message delay.
Yes, it's theoretically possible to adapt many protocols to many use cases, but that doesn't mean it's a good idea. Email and XMPP are just geared towards very different use cases.
In particular, Email has a lot of assumptions about acceptable delivery delays, bidirectional (non-)reachability etc. baked in that would be very hard to globally undo.
As programmers, is it not our natural instinct to create a ChatSystem and MailSystem on top of a GenericMessageDeliverySystem? When did we stop doing that? Creating a brand new GenericMessageDeliverySystem for each purpose comes with substantial costs. We don't reinvent the Internet to create WhatsApp.
What generic message delivery system are you talking about, though?
SMTP is optimized for the use case of email; XMPP is optimized for one-to-one instant messaging; Matrix is optimized for "Slack-like" chat.
I highly doubt that these three use cases are similar enough to warrant introducing an additional common protocol/layer.
Optimized how?
I think the point is that it builds on existing infrastructure that almost everyone already has in their life. Whether you self-host, use a niche provider, or a mainstream provider, email provides a pretty interoperable starting point which isn't a walled garden and doesn't have to be owned by FAANG.
Are there some compromises? Of course. But creating new accounts, or using new services isn't one of them. Email-speed instant messaging is good enough for me.
And to be honest, as much as I like Matrix, it has plenty of compromise of its own - including speed/reliability when using their own servers.
From the website:
> Reliable instant messaging
If it's based on e-mail, it's just not. (if we assume generally close-to-realtime delivery and not being blocked by random recipients)
Email is a communication system with a lot of moving parts. You can't have reliable IM through existing MX servers but you may have it if for example SMTPs are running on your machine and you poll their data more (it's just an example, I know that with an SMTP running on your phone you'd have more problems).
See earlier on today's front page, another all in one mail server. It is much, much simpler than it was to do this. I've been self hosting email for nearly 20 years and the state of the art is considerably better now. Latency is virtually nonexistent and federation works.
I'd say it's good enough - but I refuse to call a conversation over email "reliable" as in the properties I expect from a realtime messenger.
It's reliable, it conveys messages, but not instant at all.
I mean... WhatsApp is literally XMPP / Jabber... It's amazing that we didn't stop and said, wait, Jabber can do this, we just need a pretty UI...
Hell, Jabber can still do this. I'm not convinced of the other modern alternatives that don't have half the functional capabilities that Jabber do.
The only "downside" of Jabber is that it's XML based, but really if you think about it, that's a strength. Anyone here could probably parse the protocol effortlessly. There's also lots of fully functional clients out today, and servers that scale like nobody's business.
I'm more ashamed we don't invest more into XMPP: Google Talk, Facebook Chat and WhatsApp were built around it. These are companies with insane to scale userbases, tried and tested.
Here's a 2008 article from Facebook on using their chat with a Jabber client:
https://developers.facebook.com/blog/post/110/
> it's XML based, but really if you think about it, that's a strength
Nope.
Another downside is the X. The protocol being extensible means that no two clients implement the same subset of extensions making it useless. I’ve been scolded in the past for using the "wrong" client, making my messages look weird for people using the "right" client. Just make a good protocol.
> "Wait, e-mail can do this, we just need a pretty UI"
This reminds me on this nice comment thread: https://news.ycombinator.com/item?id=19217818
i have been arguing this ever since ICQ became popular. back then i got a lot of angry reactions. i already explained it here: https://news.ycombinator.com/item?id=38029579
that generic server backend that i am describing in my linked comment is something i am using here: https://news.ycombinator.com/item?id=42159045
https://news.ycombinator.com/item?id=9224
For those unaware, this was created by Holger Krekel, the brain behind pypy and pytest! Another great product.
didn't knew that!
Even though I am part of this secure messaging group chat on matrix thing and I had even created a whole tierlist of security of protocols etc. and saw delta chat & have it running and fiddled with it.
The fact that it is written by creator of pypy is wholesome!!
On the positive side, the use of P2P and IMAP makes censorship difficult, which is a strong advantage in authoritarian regimes.
However this comes with serious trade-offs. PGP lacks forward secrecy: if a key leaks, all past messages can be decrypted. Also IMAP offers no metadata privacy, anyone can see who you email and how often.
Signal and WhatsApp are likely a step ahead in terms of privacy with their double ratchet encryption (https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm).
> Signal and WhatsApp are likely a step ahead in terms of privacy
WhatsApp is closed source, so whatever they claim to can't be proven. And remember that both WhatsApp and Signal are legally required not to disclose to you whether they are spying on you or not.
> WhatsApp is closed source, so whatever they claim to can't be proven
E2E only requires a correctly-designed client, not a correctly-designed server.
Since any binary can always be deobfuscated, deliberately putting in a backdoor in the client would be an extremely risky PR move, especially in an app as big as WhatsApp, and one surely receiving lots of attention from security researchers.
Not to mention that OpenWhisperSystems (the creators of Signal) worked with Meta on their E2E implementation, and if you don't trust them to do right, you shouldn't trust anybody.
Let's face it, people over here just don't like Meta and love to spread FUD about them.
One trust is lost, it's hard to regain it. The fact is, the WhatsApp client is not open source, there are no reproducible builds, and only thing you have is trust in them.
If you live in an authoritarian state with a track record of spying on individual citizens, and without legal protection for the privacy of foreign citizens, it's legitimate to decide not to trust a company like Meta headquartered in the USA.
> The fact is, the WhatsApp client is not open source, there are no reproducible builds, and only thing you have is trust in them.
That is not strictly true. It is possible to reverse-engineer the client. It's unlikely that anyone will find the motivation to do so, but there's no law of physics that says they can't. You can theoretically review the code that is running on your device - it's just harder than with an open source reproducible build.
What would be the consequences, if Meta was caught doing something "funny" with e2ee? Maybe small fines, and a brief online moral panic, but I don't think people would switch to another app en masse solely because of that.
I love this optimism, I really do. But to believe that any meta product can be private is to believe that Zuck actually wants that to happen. Zuck, the guy who changes company culture every 4 years or less to suit whoever is on the white house. The reality is that with a closed source product, you can't trust ANYTHING. Just because OpenWhisperSystems worked with Meta doesn't mean anything. Meta will easily silence them legally if they wanted to. And Meta can always remove or disable the implementation as they see fit.
> Since any binary can always be deobfuscated
Are you talking about decompilation? This, is in general very difficult, and that's when the author and compiler don't want to stop you from doing it.
Go fire up jadx or ghidra or whatever you like and see if you can find the bits of code you know are there. Now try demonstrating that a bit of code isn't there.
So you trust without proof. That's nice.
>Let's face it, people over here just don't like Meta and love to spread FUD about them.
It's called punching upwards.
>Since any binary can always be deobfuscated, deliberately putting in a backdoor in the client would be an extremely risky PR move, especially in an app as big as WhatsApp, and one surely receiving lots of attention from security researchers
Correct me if I'm wrong, but can't a proprietary delivery mechanism such as the App or Play stores deliver a backdoored build to an individual device, then later autoupdate it to a clean one?
Builds are signed by the software publisher, not the Play Store. So the store alone couldn't corrupt releases, it would need collaboration by the publisher. (Google does have a service for app developers where they keep and manage your signing keys for you, but it's not required)
Interesting! Who checks those signatures?
> Let's face it, people over here just don't like Meta and love to spread FUD about them.
Yep, don't like it. They already have proven to not be trustworthy by various privacy scandals in the past
WhatsApp obviously cannot be trusted for message privacy for the simple reason that Meta paid gazillion bucks for it. I don't understand why people need more evidence beyond that.
the cant read your messages. thats the usp of using signal encryption
its the rest of the account and metadata that is at risk
Do you think your whatsapp application is end-to-end encrypted on your device? They control the client so anything is possible.
well, thats the stated functionality! hahaha
If your device is confiscated your entire history is in the clear. Forward secrecy doesn't magically solve problems, it's useful if you use ephemeral messages. In DC if there's a window of time where you want messages to not be traceable you just create a new email adress (which is just one click in DC thanks to chatmail) and delete that address after, that's it.
> if a key leaks, all past messages can be decrypted
Not to mention, if you revoke a key (maybe because you lost your laptop and want to be proactive about security), without any authenticated timestamping service in the mix, all past messages and signatures can no longer be trusted, regardless of the revocation date. That's why when you revoke a key on github, all your previous commits' signatures turn red.
I've never understood why no one's succeeded in doing anything about this after all these years.
edit: I was wrong, Delta Chat now has forward secrecy from v1.48: https://delta.chat/en/2024-11-20-webxdc-realtime
Furthermore metadata transparency can be made less problematic by using email aliases.
forward secrecy seems to apply to realtime connections, not to messages sent over SMTP.
now what's interesting here is a potential future development of deltachat where SMTP is only used to negotiate the peer to peer connection, and the actual chat messages are sent over the direct connection. although it sounds kind of weird to build a chat solution on top of SMTP and then bypass SMTP in the end.
the remaining benefit would be the ability to talk to people who don't use deltachat. not needing another account on a new service. not needing to develop or maintain server infrastructure.
wait, in a way it's already there: https://github.com/ArcaneCircle/live-chat
now adapt that to storing messages... ;-)
Previous discussions:
24-jan-2021 https://news.ycombinator.com/item?id=25893626 148 comments
07-jan-2021 https://news.ycombinator.com/item?id=25674894 4 commments
27-feb-2019 https://news.ycombinator.com/item?id=19263357 11 comments
21-feb-2019 https://news.ycombinator.com/item?id=19216827 56 comments
03-feb-2017 https://news.ycombinator.com/item?id=13560279 1 comment
Several years ago I tried DeltaChat and it caused an insurmountable problem: my mail provider kept locking me out of my account. Almost certainly it was because DeltaChat's suspiciously ciphertext-filled messages were triggering the abuse lockdown.
The provider was GMX and it was their fault, not DeltaChat's. But I had to call off the experiment.
> The provider was GMX and it was their fault, not DeltaChat's.
Noting that the team have put together "Chatmail" a minimal email suite designed for speed, security and convenience.
Also helps with the whole "onboarding to chat" and multiple identities not linked to existing accounts.
https://delta.chat/en/chatmail
There are multiple public servers which may be an option, instead of using an existing email account at provider X.
The most important factor with email, is that your inbox is encrypted at rest at all times... and cannot be bruteforced.
The chances of your email messages being 'man in the middled' are almost non-existent. Its a micro-percent of live investigations that does this.
The police RELY ON finding messages in either your inbox or the recipients. It doesnt matter if they are encrypted or not in reality. Of course they'd like to read them and if they are this deep into you. Its likely they still will (probably from the recipients lesser password hygiene than yours).
Almost no evidence is every 'plucked' out of the air and read. It just doesnt work that way.
However, software like Delta is better than nothing esp for normies. Its just limited in use for people who really need ways to frustrate LE.
Source: Ive been under NCA and FBI investigation before. Protonmail with the two password method stopped them every time. Memorise the 2nd password and password manager the first.
> Ive been under NCA and FBI investigation before. Protonmail with the two password method stopped them every time. Memorise the 2nd password and password manager the first.
Unless you exclusively use proton-bridge and disabled auto-update, then proton controls all endpoints in which your passwords live.
So what is preventing the FBI from forcing Proton to serve a special UI just to you that will be used to exfiltrate your second password?
Nothing if I was a tier 1 Russian spy. but Im not.
In the US you might be able to argue it amounts to "compelled speech", and is unconstitutional.
https://en.wikipedia.org/wiki/Apple%E2%80%93FBI_encryption_d...
You have? Why?
Because people lie on the internet
send me your email you tedious little prick
Ill show you the forms Ive got on my desk lol
just the usual dark web bullshit.
no charges but lots of attempted snooping.
fuck them
I wish I could send a one-time link to my father where we could play chess against each other by re-visiting the same link.
The e-mail part made me think of this. I have no use for an e-mail based chat but an online chess game that's easy to use without registration would be cool. He's 82 and he can't use complex sites.
> an online chess game that's easy to use without registration would be cool
Lichess lets you play without registration, I believe (or at least one player; not sure if both sides can be anonymous).
Lichess was indeed perfect. I was hoping for a self-hosted solution like hedgedoc but lichess does what it needs to.
well then deltachat is exactly what you want because it supports webxdc apps which can run in the deltachat client. here is the chess app: https://webxdc.org/apps/#arcanecircle-chess
My first question on this sort of thing was how well does it work with GMail. And they have an FAQ entry on it: https://providers.delta.chat/gmail
I'm pretty sure you would be quickly rate limited, especially if you participate in a few large group chats.
Would love to know if someone actually runs it reliably. Especially with a Workspace email address.
The whole purpose of using a distributed IM like Delta Chat is to break free from big data leeches like Google. If you're just using Delta Chat with a centralized Gmail server as the backend, doesn’t that defeat the point?
at one point that used to be how email worked too. for me the point of using deltachat is that it works with my existing service and that it does not depend on any particular company/service. issues with google are secondary. deltachat is still useful even with gmail.
Reminds me of Topicbox (by Fastmail).
https://www.topicbox.com/
I tried to use it, liked the concept, but the way it handles email is a mess, making it unusable for my use case of trying to use it as an alternative mail client for my normal mail account.
I tried it a couple years ago and it sorted everything neatly into a Deltachat folder. But a friend of mine also complained abut too many mails
The issue is, if an email is sent to one of my aliases, instead of seeing one conversation between the sender and a recipient (my alias) every message creates a new group chat with the sender, my main account and my alias as members. For every single mail, even when all members are the same, a new group is created. When I reply in that group, then the email will be sent to all group members, including the original sender, and my alias. And sender would always be the main account.
This is a known Delta chat issue, but they deem it too niche to consider properly supporting aliases.
In an ideal world, when an email arrives, it should create a conversation between a sender and a recipient (alias) without adding a main account as a member. Sending a new message in that conversation will automatically use an alias as a sender. For new chats/conversations, I should be able to choose which alias to use.
Then I would be able to use it as a chat UI for my mail messages.
a long time ago i envisioned that mail clients should really display mails as a conversation just like you describe. a list with all my contacts. and opening the contact gives me all emails received and sent with that contact.
if you want to use different aliases in deltachat, i think the best option for now is to create different deltachat profiles for each. you can have multiple profiles active at once and you get notifications for all of them, you only have to switch profiles to see all the messages. switching profiles is a single click and feels like switching folders in traditional mail clients.
Yes, but the issue is they all share the same inbox, and my email server doesn't support server-side incoming filters so I can distribute mails to separate inbox folders that would be monitored by DeltaChat.
Alias is a standard email feature. If Delta Chat want's to be usable as a general mail client, aliases should just work.
you are right. i haven't thought about the shared inbox. deltachat would have to have support for that in some form.
"I used a hammer to make orange juice and it made a mess! Unusable!"
would be nice if all the "no, no, this can't work! email is slow! blah blah" guys once and for all actually give it a try to the app and realize IT WORKS AND IT IS BLAZING FAST! I have been using it since years with my family and some friends without any problems, it is the best I could find after trying Matrix, XMPP, etc.
Does it means the delta chat messages appears in the regular mail inbox?
It's configurable. As per their FAQ:
https://delta.chat/en/help#why-can-i-choose-not-to-watch-the...
https://delta.chat/en/help#why-can-i-choose-to-only-watch-th...
Ah the famously friendly UX of PGP combined with the solid reliability of email. This is trying to get two drunks to stand up straight by leaning them against each other.
> This is trying to get two drunks to stand up straight by leaning them against each other.
Thank you for painting this beautiful picture.
Presumably they have chosen and standardized a particular subset of PGP for their product, making it fully reliable and user-friendly.
They've actually cracked PGP, and email is fine, especially between self hosters and anyone using chatmail. I've been using it for years: Delta really, really works.
Can you clarify "cracked"?
PGP has been cracked when you use it with automation in that you can steal keys slowly by relying on the meta-behavior of systems around PGP. A classic attack here is timing how long it takes for a PGP-based automated system to reject your messages.
PGP is intended for the classic "used by a human to encrypt emails manually" flow and is actually insecure if you automate around it.
I'm fairly sure they meant "cracked" as slang for "solved", as in "I've cracked the case."
the timing attack you're describing is extremely common -- not unique to PGP -- and simple to mitigate. do you have more literature about the attack, or attacks, that you're describing?
You should really try the thing in question before commenting
Have you used it?
Slap AI, blockchain and electron on it and ship it, stat.
Very secure, too. You get all the insecurity of automated use of PGP combined with the insecurity of using email protocols.