Delta Chat is a decentralized and secure messenger app
Previous discussions:
05-mar-2025 https://news.ycombinator.com/item?id=43262510 100 comments
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
Great source of info.
I wonder why this was downvoted
Delta chat looks great, and reusing the existing infra is a huge boon. However, it has the same issue of hard reliance on a specific server for connectivity.
Why do every system insists on having persistent names as network identifiers? Practice shows that the main threat for the vast majority of users is state censorship. In case of Delta, Matrix, XMPP and others, once you're cut off your home server, your account is basically toast. The only thing you can do, besides circumventing, is a cumbersome and messy account migration[1], where available.
In case of Matrix, I feel very bitter, as I managed to onboard a considerable chunk of my personal network but most of them can't login anymore without using VPNs. I'm not sure if I have enough social capital to convince them to repeatedly register on different servers as they get blocked. P2P[2] feels still too far away.
Why can't we use key pairs as identifiers and simply request a desired username upon first login? In case of federated networks this would allow seamless server switching and allow users to continue their conversations. Servers shouldn't care what server a particular user's messages are coming from as long as they are verifiably theirs.
You can even add username propagation between servers (a new server requests the username from the old one that's supplied with user's login request). I know about Matrix identity servers but I don't see how it helps in this case.
"No, Delta Chat doesn’t support Perfect Forward Secrecy (PFS). This means that if your Delta Chat private decryption key is leaked, and someone has collected your prior in-transit messages, they will be able to decrypt and read them using the leaked decryption key."
https://delta.chat/en/help#pfs
It's great they're being open about the implications. But given that there's better protocols out there (Signal protocol for example), it makes no sense to use inferior apps.
I'm not sure that's fair. It would be if it was otherwise just another messenger app, but Delta uses email as a transport, which gives it a special kind of resilience. It's harder to shut down email than signal.
I don’t think this is true in practice. On the whole, I suspect the ordinary user of email is exactly as centralized as the ordinary user of Signal.
(The response here might be that you could run your own mail server, but you’ve now excluded >99% of the world’s population from the essentially reasonable expectation of secure messaging. Plus, you’re then dealing with the ongoing misery of securing your own mail host.)
> I don’t think this is true in practice. On the whole, I suspect the ordinary user of email is exactly as centralized as the ordinary user of Signal.
Not true, because an open standard will always be superior to a company-owned (and controlled) app.
I run all my own email infrastructure. Many of my friends do. We can communicate without any corporate overlord deciding who can say what.
Signal is a company, one that demands a phone number to use their proprietary service and can shut you out in a nanosecond. No thanks.
Signal is not a company but a non profit, and their service is not proprietary but fully open source including the server side. That being said, it is centralized and so less resilient, it can be taken down more easily. So you have to pick between more secure (Signal) or more resilient because decentralized (DeltaChat). Theoretically Matrix has both, but at the moment it is not as secure as Signal, and its UX is clearly worst. And to that you have to add the complexity of decentralization for normal people: which server to pick, how can I know if someone I know has an account... Here the comparison with email should help but still it is not as easy as entering a phone number and immediately you have all your contacts available.
when you say “Matrix’s UX is clearly worst”, what app are you talking about? Element X is similar if not better to Signal in terms of UX for instance.
The difference is the collateral. Are you really going to shut down a country's most popular local email service? Or gmail?
I think the answer to that is resoundingly yes: the kinds of countries that care about curtailing E2EE messaging are also the ones that institute nationwide internet blackouts.
(But also, this isn’t a good argument! Repressive governments love metadata, and email is an amazing source of unbounded metadata even with these kinds of “secure” layers slapped on top. If I was a government looking to snoop on my citizens, I would absolutely push them towards the protocols I can infer the greatest amount of behavior from.)
Blocking email or gmail is much closer to a nationwide internet blackout than blocking signal or tor. And even repressive regimes are on a budget there.
I'm not sure your second point holds either - for most nations, an active connection to imap.gmail.com leaks little other than how actively the user uses gmail. Correlating senders and receivers from that data sounds technically challenging enough that I wouldn't expect repressive regimes to be capable. But, to be fair, I base that on nothing.
> Blocking email or gmail is much closer to a nationwide internet blackout than blocking signal or tor.
Yes; the point was not that they’re the same, but that regimes that do the former tend to also do the latter. Moreover, we shouldn’t do insecure things because regimes block the secure things; that’s what the regime wants you to do. The answer might not be Signal if Signal is insufficiently decentralized, but it certainly isn’t email.
> for most nations, an active connection to imap.gmail.com leaks little other than how actively the user uses gmail
This alone is a significantly larger amount of metadata than schemes like Signal leak. But it also isn’t true: a country that controls its internet infrastructure can almost certainly pull much more metadata from plaintext IMAP/SMTP than just access times and addresses. And this isn’t hypothetical: STS is not widely adopted in the email ecosystem, so plaintext downgrades are pervasive.
> I'm not sure your second point holds either - for most nations, an active connection to imap.gmail.com leaks little other than how actively the user uses gmail. Correlating senders and receivers from that data sounds technically challenging enough that I wouldn't expect repressive regimes to be capable. But, to be fair, I base that on nothing.
Nations don't have to do any of that, they can just subpoena the email host for the data, or just ask nicely for it, as companies are wont to work with law enforcement and the regimes they do business with.
The point of many of anonymizing and "private" chat services is the lack of data sitting on third-party hosts that can later be shared with adversaries.
you don't have to use email to federate between servers, there are other protocols such as Matrix, XMPP, probably many more
I was not talking about federation, I was talking specifically about email. It's like the domain fronting feature that signal used to have, but using a service as a front that is business critical.
"It's harder to shut down email than signal."
It took me two minutes to figure out DeltaChat connects to the server with SNI "nine.testrun.org". Banana dictatorships can trivially write firewall rules to cut those connections. There are other servers, but if those are going to be usable by anyone, they're going to have to be public, and writing block-rules is trivial compared to spinning up new servers.
I'm not saying Signal is much better in this regard, I'm just saying resilience isn't a useful metric to assess messenger security.
DeltaChat connects to the server with SNI "nine.testrun.org"
sounds like a bug that can be fixed. it should not need to make that connection unless you create an account on that server.
No that's just the default behavior of connecting to default server, which is what 99.9% of users are going to do. You want to get rid of SNIs, you run a server dedicated for DeltaChat, and then its the IP-address can be blocked.
connecting to default server, which is what 99.9% of users are going to do.
not quite. the default server feature is only a year old. while deltachat itself goes back to at least 2017, so the majority of users will not be on that default server now, and it would be possible to offer a randomized selection to prevent one default server from dominating.
Majority of new users will be. It's still a niche product.
Also, I'm unsure if it's smart the client just picks a server for you at random. AFAIK this uses email as back-end so it's not like you can just swap your email address host like you can swap telco while keeping your phone number. One option would be to have the user first whitelist the email providers they'd trust, but most users usually prefer trusting the app vendor as they're trusting it with the client anyway.
Modern XMPP clients implement the Signal protocol for encryption and are decentralized like Delta Chat.
XMPP is riddled with privacy pitfalls even when you bolt on encryption to it. Like email, it was not designed with privacy in mind.
forward secrecy is under discussion:
It's email-compatible and uses pgp for encryption. No forward secrecy and supports sending unencrypted messages as well for people who don't have pgp.
No forward secrecy and will automatically switch to unencrypted messages if you receive an unencrypted message from a contact.
I wonder if it's vulnerable to downgrade attacks from adversaries falsifying the sending address. If an adversary sends an unencrypted email imitating a contact will delta chat reject it or will it silently switch the chat with that contact over to unencrypted email?
The way to have guaranteed encryped is creating two user encrypted group chat.
https://delta.chat/en/help#how-can-i-ensure-message-end-to-e...
did you look into their spec? perhaps they used the updated openpgp standard which has authenticated encryption. or perhaps they just sign everything.
and it's not just pgp with email, it's more akin to an overlaysystem.
>No forward secrecy and supports sending unencrypted messages as well for people who don't have pgp.
JFC. There's a reason Signal dropped SMS support. What an insane design decision.
FWIW textsecure (signal's SMS predecessor) did provide forward secrecy. Details are here: https://signal.org/blog/asynchronous-security/
Yeah but it later also supported non-E2EE SMSs and those were a security risk and they rightfully dropped the support. It was not ideal your grandma thinks any message sent in Signal is safe, when that wasn't the case.
Why not 0xchat?
Private key login, encrypted private chats and contacts, encrypted group chats, and lightning payments. Decentralised, built on Nostr. Available on all platforms.
https://github.com/0xchat-app states it doesn't have desktop clients.
Also, the direct messages have three types
1) NIP-04 DM: "Most widely used", but also, "not recommended". Reeks of Telegram that also has non-secret chats being the most popular option
2) Gift-Wrapped DM: Uses different encryption algorithm but no forward secrecy? Forward secrecy has been around for 20 years.
3) Secret DM: Can't be recovered on different devices. Why can't the backup be self-contained database like Signal has?
Also "Secret chat requires consent from peer." Like what :D You have to wait for contact's approval to have a private conversation with them. Sounds like it incentivizes all chats to start with less secure protocols.
The nice part about writing your own chat system is the security agility in that you can bump any security property without having to fight with protocol standardization bodies. Having three DM protocols inside the same app is wild.
I think the point here is that everyone has email. A chat client built on Nostr is fine (and I want to love Nostr), but it just doesn't have the reach or ubiquity of email.
Nor does Delta. Nobody will “chat” with me via their Gmail email focused UI, so it’s effectively a separate network anyway.
Using an email address as an identifier for IM is a great idea (I hate that everything uses phone numbers for this, which are not internationally portable and not possible to reasonably “self-custody” the way TLDs are).
But using the actual email protocol as a backing protocol for instant messaging seems like a weird contortion and still makes this effectively a separate protocol, the split being servers that do and don’t support all necessary extensions. The overhead must also be staggering; just look at an email header to see how much is going on for each message these days.
you got a point with the overhead in email headers. also an email is sent not only for every message but also status updates. that adds up to a lot of emails.
When you start looking at alternative messengers outside of Matrix, XMPP, and IRC, there isn't much where third parties can operate or implement both servers and clients.
Certainly if no one can implement these two things it is functionally a closed source project. It also is a security failure from the standpoint of control, validation, and also future security and vulnerability patching (there's a graveyard of dead "secure" messaging apps.)
Is DeltaChat perfect from a security standpoint? No, but it's certainly well above the hurdle most people are at now. Most people are using non-encrypted communication that is actively scanned & stored, or e2e on paper stuff where one party controls the client, server, application, and storage (trust me e2e security.)
Telegram, Discord, Facebook Messenger, stop using that shit.
>Is DeltaChat perfect from a security standpoint? No, but it's certainly well above the hurdle most people are at now.
It's less safe compared to Signal, and Signal is the gold standard recommendations for average Joes. "Better than Telegram" is a low bar.
telegram is the most user friendly chat out there. the only ones that compete in usability are wechat (yes, the chinese one) and, deltachat. signal just got a bit better by finally allowing me to hide my phone number. of all these, deltachat is the only one that doesn't require a smartphone and a phone number.
Telegram indeed does have excellent UX, speed and multi-device support.. as all clients are open source, there should be a (convoluted, rocky) way to port them to use the matrix protocol (an idea I've had a couple of months back).. or, instead of one-time porting, insert a protocol bridge running as sidecar in order to be able to keep in sync with upstream TG code (Pavel himself seems to be doing _immense_ amounts of coding on it)..
Anyone up to the challenge?
>telegram is the most user friendly chat out there.
Telegram is a walking time bomb with 900 million users' data waiting to be leaked from the servers.
>and, deltachat.
That must be why I've never heard of anyone using it.
>deltachat is the only one that doesn't require a smartphone and a phone number.
It leaks the IP-address to the server, which by default (defaults matter) is nine.testrun.org. That server can amass metadata about users conversing, and any government entity that comes knocking can look at TelCo records about to which user the IP-addr was assigned at the time.
If you're going to try to address metadata privacy against service provider, you're going to have address it properly, and DeltaChat isn't the one at that point. Neither is Signal. You'll want Cwtch for that.
> Telegram is a walking time bomb with 900 million users' data waiting to be leaked from the servers.
Russia probably has all the Telegram data, considering they officially intervened in the recent Romanian presidential elections taking the side of the local MAGAs.
https://www.reuters.com/world/europe/telegram-founder-says-h...
What the article doesn't say is they sent a message in romanian to all romanian telegram users with the above claim, signed Durov.
So I don't think their "security" can be trusted.
nine.testrun.org is owned by deltachat developers. it is about as trustworthy as, say, matrix.org. the only better alternative would be self hosting.
the question is not what is the best, most secure, most private, option, but what has the right balance between easy onboarding, ease of use, security and privacy. and maybe deltachat is not the best possible, but it is pretty good. remember, when security and privacy are to onerous then you don't have security or privacy because people will refuse to use the tool.
>the only better alternative would be self hosting.
Which doesn't really work in practice. The closer you move to the user, the more the threat of creepy buddy watching over metadata of people they know grows. Medium sized institution like university or a company might run their own, but that's also somewhat risky.
>the question is not what is the best, most secure, most private, option, but what has the right balance between easy onboarding, ease of use, security and privacy.
No. The question is, given an architecture that imposes fundamental limitations on what can be achieved, which tools under that domain have best privacy by design system, where the UX and features are maximized with ingenious design, is the best.
Fundamental architectural limitations:
Does Delta Chat use data diodes? No? Then it can't have key exfiltration security, but it can have message forwarding.
Does Delta Chat use Tor Onion Services? No? Then it can't have proper metadata privacy for users' identity from the server, but it can have offline messages.
These are fundamental trade-offs.
DeltaChat is content-private by design. It might be metadata-private by policy (internal policy that server on nine.testrun.org does not collect metadata), but until that is tested in court like Signal is, we can't know for sure.
Signal is content-private by policy. Cwtch uses Tor Onion Services so it's metadata-private by design.
Now, it's fine to argue which is the best inside one league.
Element/Matrix is E2EE with double ratchet protocol, so it has both forward secrecy and future secrecy, which DeltaChat doesn't have.
It's only once security is more or less exactly on par, that you should be comparing general UX. Really usable but insecure tool might turn into really unusable tool when you sit in prison for your political opinions, or because you revealed your ethnicity and ICE caught on.
>maybe deltachat is not the best possible, but it is pretty good
It's not the worst out there. At least it tries to do things properly. It's just that given that there's insane obstacle of moving people to a safe platform, DeltaChat is just another distraction. Until it does what competition does security wise, and improves on their UX, it doesn't get the top podium.
>when security and privacy are to onerous then you don't have security or privacy
Sure, but when you're in prison for using crap tool, you won't have liberty, security, or privacy.
It's only once security is more or less exactly on par, that you should be comparing general UX.
ideally yes, but that is not what the average user will do, and it is not what i can use as an argument to get people to switch to something more secure. convenience over security is still a user preference.
i get your point, but that falls on deaf ears among family and friends. especially using prison as an argument is really not helping. i mean by the same argument we should not be having this conversation on hackernews, because clearly we are trying to subvert the authorities by suggesting that people should keep their communication secret.
Apologies for any nativity here, but wouldn't storing encrypted messages on a blockchain be a robust solution for this?
Why would you want that? The last thing I'd want in a secure messenger is a permanent ledger that holds message content and associated metadata which anyone can analyze.
edit: I didn't downvote you and I don't think someone asking an honest question like this should be downvoted
Doesn't Nostr expose the fact that you sent messages to certain people via its blockchain?
Nostr doesn’t have a blockchain or token.
Notes and Other Stuff Transmitted by Relays.
It’s just signed json messages distributed by [websocket] relays.
I'm probably mixing up analogies with actual implementations, but I'm basing my question on sentiments like this[1]:
> While nostr offers the ability to send encrypted DMs to user pubkeys, the metadata of these messages are broadcast publicly via relays. This is the same as a bitcoin transaction being viewable on the public ledger. The contents of the direct message will be encrypted, but other metadata like the sender and recipient can be viewed by anyone.
Your intuition is correct, Nostr objects are stored on relays and can be retrieved by any client with the proper private keypart. In my test runs of trying Nostr proper for a month or two, I had problems deleting objects (clients lack support for the NIP API calls was common) - and you can only delete your end of a DM, not the whole thing. (another frustration - your "chat" or "inbox" can never be cleaned or deleted of the other person's messages).
Effectively nostr objects lay around on relays until they reach some server-side expiry policy and sometimes forever if one can't figure out how to delete them. Nostr clients (web and mobile) are the wild west of good luck with which features and NIPs they support (XMPP all over again). My experience here led to dissatisfaction as well. Relays are another wild west - it's choice paralysis and a helping of good luck with that.
The real problem for IM: Nostr does not ensure all relays sync, instead a user chooses their preferred relays (some you pay for in crypto). It is entirely realistic (I experienced it) that you're on relays other people aren't and you can't share content. This is death for an IM app and just trying to use Nostr became frustrating. (not to mention it's flooded with porn and crypto shills)
Edit: a nostr client has to keep open network connections to all these relays, as objects can be stored on multiple relays and it's up to the client - not the relays - to query all relays and then de-dupe the JSON responses. There are combobouncers in use (who will de-dupe) but they're not the default and tend to be read-only (because you can't choose which relays to post to when using a combobouncer).
0xchat on the surface seems better: looks like a professionally maintained codebase, with clear ways to interact with the devs.
But - has there been security audit been done?
Is it just me or does the website render poorly on mobile?
If you want to migrate to a different chatmail server is it possible to keep that same chat alive or do you have to create a new one and the old stays in the history? This is already how it is with whatsapp but it is a pain point.
An email address is your Identity; while it's possible for you to maintain the same chat when you migrate, you'll sever the chat for the other person because they have to chat with a new Identity (your new email). (think the email headers to/from, you've kept "to" but changed "from" for them, but it could use the same PGP keys to decrypt etc.)
this completely sidesteps the infra bootstrapping phase. there's no need for new servers, federation drama or client network lock-in. every user already has a compatible backend = imap + smtp. that shifts the challenge from adoption to UX. that's a very rare position for a comms tool to be in. this's refreshing to me personally, would love to contribute to the mission
Anyone else immediately think of delta airlines? I was excited to read an analysis of a seat-to-seat chat implementation
seat29@flight7822.delta.com slaps seat34@flight7822.delta.com with a large trout :: stop snoring
Like those gaggles of girls chatting each other up while walking shoulder-to-shoulder down the street.-
I'm curious how spam protection works if you're an alternative, few users, chat app? I hate Meta's monopoly as much as the next guy but one thing you do have to credit them for is the second to none spam protection. I also wonder how much requiring a cell number is part of that strategy.
It's just email and gpg so you'll get the same spam you do normally.
IMO people freak out about spam way too much. I'd rather have something that works with occasional spam than have to put up with the insanity of modern IM. Having push notifications from 10 proprietary IM apps is worse spam than a couple of emails a day from some retard trying to get me to download a "pdf." I don't block spam at all in my personal email (although I have a couple of tools automatically label it.) I'd rather have everything delivered.
i run my own email server, using a spam filter i set up years ago without explicit blocking (only tagging and filtering) and didn't touch it since. the amount of spam i get is negligible. a few false positives, but nothing serious. in fact it's so little i could probably just leave all the spam in the inbox. it is tagged as spam anyways.
I've just been the target of some spam "campaign" on my own email server. By the time I was annoyed enough to block some IPs and add a custom spamassassin rule for them, they had already stopped. It lasted two days.
Other than that it looks like I get like 4 spams per week.
Mind, i don't publish my email anywhere. If you look at my profile on here you'll get a gmail address.
I have my own email server with a wildcard address (I still use gmail for anything that's actually important). I put certain addresses in shady forms a few times. I get a couple of spam messages per day to those addresses - always the same spam few spam campaigns. One is offering to sell me electric bicycles or partner with me to sell electric bicycles (didn't really pay attention) and more recently I started getting business proposal advance fee spam. The volume is pretty manageable and if I wanted, a pretty simple filter tuned for the spam I actually get would catch all of it and no ham.
I got spam to postmaster once for some reason. That's a nice way to make admins aware of your spam campaign.
Spam is presumably more of a problem when you're more well-known and you don't have the option to control your own filters.
An alternative few users chat app probably won't be a major target for spam untill it has lots of users.
So I would say it's a low priority feature in the backlog.
You can design your way around it
1. Manually screen who can send you messages like Hey[^1] and Apple[^2]
2. Basic filtering to ensure the promotional stuff gets blocked or put in a separate list [^3]
3. Rate-limit senders who are showing robot like behaviour
---
[^1]: https://www.hey.com/features/spam-corps/
[^2]: https://support.apple.com/en-il/guide/iphone/iph203ab0be4/io...
deltachat distinguishes between normal email and deltachat messages. you can limit to the latter if you only use it to communicate with other deltachat users.
If your need is security then really that should be based on in person trust.
Or at least via a proxy.
So contact invitation can just be handled with use-once codes (or at least trivially burnable ones).
I wouldn’t necessarily agree that WhatsApp‘s spam protection is that great. I’ve been invited to quite a lot of pyramid scheme/scam WhatsApp groups, however that’s mostly happened after having to expose my private cell number on the internet (thanks to app stores and GDPR requiring some kind of phone number for businesses of any size).
afaik no businesses are required by the gdpr to collect phone numbers, and would like to see evidence otherwise
Sorry, I should have been more specific. In Europe (or Germany at least) it’s required by law that you provide an imprint with contact information for every site you host, as well as a privacy policy that includes contact information of your GDPR officer if you collect any kind of personalized data. Since I’m a one-person company, that includes my personal phone number since I don’t have a business phone. Also chrome webstore for example requires a phone number if you host an extension on there.
Edit: Also this wasn’t about collecting phone numbers, but about providing one for your business if you host a publically accessible site
There are no occurrences of "cell" or "phone" in GDPR, and the only relevant occurrences of "number" are about "national identification numbers", which phone numbers are not.
... always wondered if the cell phone requirements are not (also) tied to then wanting an actual, physical, person behind each account - as in most EU jurisdictions each SIM card is tied to an actual ID.-
In many EU countries, you can buy sim cards from some vending machine, in a grocery store or places where you can buy international telephone cards. No ID required. But phone plans are often tied to your home internet.
are you sure no ID is required to activate the cards? at least in austria and i believe in germany you can't get a sim card without an ID.
If you get a lyca sim card, even there you don't need ID to use it. There might be some restrictions after a month though.
Ah, the EU — land of fine cheeses, indecipherable GDPR popups, and, of course, the iron-fisted grip on your humble little SIM card. In the EU, you can’t even sneeze near a prepaid phone number without showing at least three forms of government-issued ID, a notarized statement of purpose, and possibly a blood sample. Why? Because buying a SIM card anonymously here is about as legal as fencing stolen paintings in the town square.-
You see, most EU countries decided some time ago that allowing people to own mobile numbers without a background check was simply too dangerous. What if someone used a burner phone to commit fraud, or worse — say something mildly controversial on the internet? To prevent such dystopian chaos, SIM registration laws were born. Now, whenever you purchase a SIM card in France, Germany, Spain, or pretty much anywhere with croissants, you have to offer your passport, soul, and, ideally, a letter of recommendation from your local constable.-
The result? Your phone number in the EU is no longer just a string of digits—it’s basically your name, address, and social security number all rolled into one. It’s like a little snitch in your pocket, ready to identify you at the first sign of online mischief. Online platforms know this. That’s why so many of them, from social networks to AI models, insist on a phone number. They’re not just trying to text you cute security codes — oh no, they’re trying to make sure there’s a warm, squishy, legally-recognizable human on the other end. Preferably one without too many fake Twitter accounts.-
Technically, GDPR is supposed to protect your data. That includes your phone number. But there’s a loophole the size of Luxembourg: if the phone number is used to stop terrorism, fraud, bots, or people being mean in the comments, then suddenly it’s all hands on deck. Platforms benefit from the comforting knowledge that EU phone numbers are like digital dog tags: traceable, trackable, and just annoying enough to prevent the average troll from spinning up 50 accounts to yell into the void.-
Of course, this all raises philosophical questions. Like: should your right to privacy hinge on your desire to play Candy Crush in peace? Is a SIM card a person? Could it run for European Parliament? And should we perhaps explore more civilized alternatives to this “one phone number equals one identity” system, like zero-knowledge proofs or just asking nicely?
In the meantime, welcome to the EU: where the cheese is soft, the bureaucracy is hard, and your SIM card knows more about you than your therapist.-
Nice post, I smiled.
There are several countries that didn't buy into the madness of registering SIMs, luckily. Most strangely, the UK, the master of CCTV. Apparently they realized that it's a useless measure and will just anger the people.
... And SIMs are available from vending machines, which I find amusing :)
Has anyone used that with their Protonmail account?
Maybe something Proton should build on for its own chat app.
DeltaChat is incompatible with ProtonMail:
They mention the bridge but if they're using pgp under the hood it may well just be entirely broken: https://jfloren.net/b/2023/7/7/0
Which party the developer associated with? Hopefully not CIA.
Pretty Good Protection ain’t good enough anymore
Yeah, that was a figure of speech. Encrypted email is probably still the most secure thing available to most people, even these days. That's because it as asynchronous and offline. You can do it in your air gapped system in your shielded and guarded basement if you really want to. That is as opposed to some instant messaging scheme running on an inherently insecure device like a smart phone where there is access to the messages all the time.
Delta Chat is an instant messaging scheme. It is still good to use preexisting standards where possible.
Why not just create a group chat and invite FBI and Shin Bet?
this is my favourite version of decentralization. building on existing widely available infrastructure. The war-proof internet.
Maybe with AI there could be a sort of decentralized antispam filtering . but maybe not
Obligatory briar mention...
Briar supports communication over multiple mediums, including wifi & Bluetooth, has forward secrecy, and feels quite 'signal-like' so its not impossible to get people to use it.
Briar cannot do offline delivery unless you setup a stand-in service. Unfortunately that's way to complicated for regular use.
Briar looks really nice for people that really need the extra security and privacy, though.
I've been interested in SimpleX lately, but I don't really have anyone to properly test it with.
Used it for years, it is great. Webxdc apps work in both android and desktop clients (not sure about iOS) so I can play chess, share calendars and to do lists, and even collaboratively edit documents, all by email, all privately.
Anyone who hasn't tried it really ought to.
To the haters talking about PGP: giving your entire social graph to Meta or even Signal is considerably worse.
Signal does not have access to your social graph[1].
(Delta Chat markedly does leak your social graph, because it's email and email has no way to protect sender metadata from each user's email provider. That means full social graph recovery is one low-effort subpoena away in your attacker's municipality of choice.)
> Signal does not have access to your social graph
Their contact discovery uses SGX, which has a long list of vulnerabilities [1], and is even deprecated by Intel.
With access to the server, my guess is that getting someone's social graph is not entirely impossible.
[1]: https://en.wikipedia.org/wiki/Software_Guard_Extensions#List...
How is the latency? All mainstream chat apps have low-enough latency that a live conversation feels fluid and natural, whereas I frequently encounter situations where I have to wait up to five or ten seconds for an email to come through. That kind of latency would kill the experience IMO.
in my experience the "latency" for a person to reply to a message is always higher than the latency for a message to arrive. in fact, some latency is good. gives you a break to think.
Besides the fact that hating on PGP is like hating on TLS. It's a spec and a container for just about anything you want to do. gnupg (the thing most people have come to dislike) isn't even spec compliant anymore and was always a power user tool not something most users should actually touch anyway
Nah, hating on PGP is like hating on SSLv3. The specs are bad, the entire system is very error-prone, and the cryptography itself is also outdated.
> giving your entire social graph to Meta or even Signal
2) you are not required to give the app access to your contacts
Stop spreading this misinformation, it is only making it harder to get people onto secure messaging systems. You need two people using secure systems to communicate and the result of all this horseshit is a bunch of armchair experts who haven't bothered to look into the actual security of the app making strong confident statements. Just stop.
Even if it had half the issues people pretend it does let's be honest, my grandma can use signal. That's a fuck ton better than most of the alternatives out there. Frankly, that's what 99% of people need, the app that everyone can use. Not the app that some techie says is trivial...
Side note) Comparing Signal to WhatsApp is wildly disingenuous.
Side side note) there's a 30 yo pgp hack. If you reply to a gpg email with "could not decrypt" you'll get back the email in clear text. (Joke is older than the average HN user)
How does this (or 0xchat) compare to Signal?
Have their been done any third-party security audits by reputable companies?
If not, it's not safe to use - who knows what's buried in the source code (even if the source code is open).
> Have their been done any third-party security audits by reputable companies?
Their FAQ answers this:
> Yes, multiple times. The Delta Chat project continuously undergoes independent security audits and analysis
Biggest advantages are the code is open, the infrastructure is open, and you don't have to hand all your metadata to a single centralized provider
deltachat does not have central servers. you get to use your own servers. aka it's federated. and it works with plain SMTP so you can just reuse the server/email account you already have.
Delta Chat has the option of using chatmail servers that they host themselves.
Chatmail relays can be run by anyone, they are designed to be fairly minimal and lightweight, just running what is needed to support the "encrypted chat" part, not regular email.
first of all, it's not a walled garden
I mean, should probably just use Ricochet Refresh, Briar, Session, Element, etc.
I also built OTR on top of Discord but it requires Nitro because the messages for OTR end up being way too long. :(
Can't they be split into lines? OTR was designed for IRC that limited protocol lines (ie. payload line + command + extra fluff) to 512 bytes, so that ought to work on Discord too.
I have not yet tried, that may work since it does work for IRC (which also has a limit per message). It was just more of a proof of concept, tbh, but it works, just not as usable as it could be.
the whole point of deltachat is that it is reusing an already standardized protocol with existing servers.
i am using element/matrix and i have tried briar. the usability of deltachat and the ease of onboarding beats both of those. briar was especially difficult to get started with and only has a very limited usefulness compared to the others. and matrix is simply very complex and easier to misconfigure.
Briar had trade-offs, for example, it is not available for desktop. I do not have use for Briar, personally. I use the rest, but Briar is worth a mention.
A standardized protocol without forward secrecy is worse than standardized protocol with forward secrecy. Just use Signal.
forward secrecy is independent of the transport protocol. it's only dependent on the encryption. messages encrypted with forward secrey can still be sent over SMTP. deltachat devs are working on that.
signal does not use a standardized protocol, and it requires a phone. that's not an alternative. my children have deltachat on their laptop. i can talk to them when i am not at home without needing to give them a phone.
>messages encrypted with forward secrey can still be sent over SMTP. deltachat devs are working on that.
OTR has had forward secrecy for 21 years. The effin headline stated PGP was a faulty model https://dl.acm.org/doi/10.1145/1029179.1029200
Why implement something PGP-like, without forward secrecy, 13 years later, beats my understanding. I mean, 13 years is also the time difference between OTR and PGP. I guess some devs don't read cornerstone papers of the field they supposedly specialize in :)
Note that while it might be decentralized and "secure", it is not anonymizing as IMAP + SMTP are far from anonymous. Email is a legacy system that was never designed with privacy or anonymity in mind.
This is useful if you want to keep the content of your messages secure, but if you need to keep your identity, social graph and the fact that you conversed with certain people obfuscated, I don't think Delta Chat via email is a good solution.
It's also only decentralized as much as public email infrastructure is decentralized.
I would go a step further: this is not secure. Forward secrecy and metadata privacy are table stakes in any modern secure messaging design, and Delta Chat has neither.
Today I learned: table stakes is borrowed from poker referring to the minimum size bet needed to participate in a hand, I’ve heard it so many times
That is not correct. Table stakes are not a "bet size", they are the minimum you have to bring to have a seat at the table. For example you might have to bring $300 to sit a table where the minimum bet size (big blind) is $5. You only have to bet the blinds 2 out of 10 hands (or more, if short-handed), which would be much smaller.
As a side note, despite its popularity, Texas hold'em is just one type of poker game. In most poker games (5 draw, 7 stud, etc..) you ante every hand.
The first N times I came across someone use "table stakes", I dyslexically read it as "table steaks". Still came to the same meaning because, yeah -- I get it -- I too would only be coming over for dinner if there are steaks at the table.
Source: https://delta.chat/en/help#pfs
It's basically GPG with better UX.
PGP?
GPG is gnu privacy guard, it's an open source implementation of the same ideas that are PGP (pretty good privacy).
Specifically we're supposed to call it OpenPGP these days
There is PGP, OpenPGP, and GnuPG, and they’re all parts of a shared ecosystem but not the same. They never were, so it’s not like anything changed over time about this.
deltachat devs are working on forward secrecy. and as for metadata, as long as the messages are sent from my personal email server to the destinations email server using a TLS connection, the metadata is accessible only on those two servers. sure, if i use gmail then google has my social graph. but so do whatsapp and telegram and others. yes, more private options exist, but for example in one group of friends right now the choice now is between whatsapp and deltachat. whatsapp because most people in the group already use it. deltachat because most people already have email. signal or matrix are not under consideration.
> deltachat devs are working on forward secrecy
That’s great, but I’m not holding my breath. PGP isn’t architecturally well-equipped to provide forward secrecy. In the mean time, I think it’s borderline negligent to put this in the category of secure messaging; the world’s expectations for security baselines have moved on beyond the mid-2000s.
(My reference point here is Keybase, which built a very user-friendly and misuse-resistant encrypted chat on top of PGP in the mid-2010s. They couldn’t get to forward secrecy either with PGP as their substrate.)
> as for metadata, as long as the messages are sent from my personal email server to the destinations email server using a TLS connection, the metadata is accessible only on those two servers.
To the best of my knowledge, MTA-STS adoption rates are still abysmal[1]. It’s a move in the right direction, but this kind of shambolic jigsaw approach to communication security isn’t appropriate in 2025. Sensitive messages should go over protocols designed to carry them.
[1]: https://www.uriports.com/blog/mta-sts-survey-update-2025/
OpenPGP is a message format standard, not an architecture standard. Since they are doing a instant messaging thing, there is no particular reason they couldn't do forward secrecy. They could even do a hash ratchet and call the result a double ratchet if they really wanted to. It would probably be more reasonable to do something a bit less obsessive and just make it so that the user can more securely delete their messages in the face of device compromise in an instant messaging environment.
"Architecturally" refers to the architecture of OpenPGP's message and certificate formats, not some kind of architectural standard. You can see Delta Chat's own community struggle with this[1]: unbounded certificate growth doesn't mesh well with acceptable rotation periods for ephemeral keys. There's also the problem of OpenPGP implementations encrypting to all subkeys instead of the "latest" one, which of course blows a hole in the FS property.
[1]: https://support.delta.chat/t/autocrypt-key-rotation/2936
The Delta Chat issue with subkeys seems to be an Autocrypt thing. Most OpenPGP implementations will encrypt with the latest encryption key.
Which brings up a point I suppose. Delta Chat is not really doing OpenPGP. They are mostly doing Autocrypt. Autocrypt was an attempt to do encrypted email without the bother of identity verification. It has always seemed like a bad idea to me. The Delta Chat project ended up adding identity verification on top of Autocrypt.
PGP isn’t architecturally well-equipped to provide forward secrecy
i have no insight into the development, but i suppose that swapping out PGP for something entirely different should technically be possible.
they did develop a peer to peer protocol with forward security for real-time messages that sidesteps SMTP entirely. seems a bit wierd given the premise, but the devs are at least not limiting themselves to SMTP and PGP.
> but i suppose that swapping out PGP for something entirely different should technically be possible.
That would probably be good, but email is still a terrible substrate for secure messaging. Clear metadata is security poison; you want as little of it revealed to participant servers as possible.
> they did develop a peer to peer protocol with forward security for real-time messages that sidesteps SMTP entirely.
That’s great, but in that case: what’s the value proposition relative to Signal or even Matrix?
the peer to peer protocol at this point is only for realtime communication at which both parties have to be present. like IRC, those messages are not saved. it does not replace regular messaging which is stored. i was merely trying to point out that the developers are capable of thinking outside of the box that they started from and that deltachat may develop in a different direction. as someone else stated, deltachat's value is that it is able to reuse existing infrastructure and does not require (but allow) a new set of servers to be able to work.
> i was merely trying to point out that the developers are capable of thinking outside of the box that they started from and that deltachat may develop in a different direction.
I mean this kindly: I wish they would think a little bit more inside the box, and converge onto a proven design.
(It’s worth noting that your “existing infrastructure” argument is exactly why Signal uses phone numbers. Using existing infrastructure is a great idea, so long as it doesn’t compromise the security expectations any reasonable user has. That isn’t currently true for Delta Chat.)
I agree from that perspective.
> Forward secrecy and metadata privacy are table stakes in any modern secure messaging design
I think this is counter-productive, limiting the adoption of meaningful security improvements. The engineering and UX implications of PFS and full metadata encryption (in particular social graphs) are severe. Not even signal has that, and they are above and beyond for a mass consumer product.
From the physical world, it’s like saying that having addresses on the letter is the same as the government opening and scanning the contents of every letter. Of course I don’t like the indiscriminate metadata collection, but there are worse things.
If you’re a spook or dissident, by all means, take extra precautions. You’re gonna need to anyway, in many more disruptive ways than your messaging app. Personally I just want to share shitposts with friends and speak freely without second guessing if I’m gonna be profiled by a data broker, or someone is gonna scan and store the pictures I send forever. Keep in mind that the status quo (Gmail, DM on social media) is incredibly bad.
No. Unless your messenger is at pains to make sure people don't use it in life-or-death situations (for instance: because they're being targeted by ICE, or the law enforcement and security apparatus of their country), the exact opposite thing is true.
These kinds of message board discussions invariably pose a dilemma: "send messages in plaintext using normal email, or use whatever secure messaging tool is available regardless of its strength". That's false. People always have a third option: not sending the message electronically. Most of us here have messages they wouldn't send even with their most trusted messaging tools; people who are at serious risk from message interception have much more dangerous messages than that.
Recommending that at-risk people use weak secure messaging as a "better than nothing" step towards real secure messaging isn't just bad advice. It's malpractice.
Metadata security isn't table stakes? I guess just pray your app's UX isn't good enough that the US Secretary of Defense decides to use it.
I don’t understand how asking for things that are bog-standard is somehow counter-productive. I think the really counter-productive thing here is flogging the dead horse of encrypted email; ordinary people deserve better than that.
> Not even signal has that, and they are above and beyond for a mass consumer product
What parts of this do you think are missing from Signal? Signal has had PFS for as long as it’s been called Signal, and has famously minuscule metadata on users.
> famously minuscule metadata
Famously minuscule? They demand a phone number, which blows up any possible anonymity story.
> What parts of this do you think are missing from Signal?
The social graph isn’t e2ee in any app that works because the server needs to route the message. And the social graph is metadata.
>Personally I just want to share shitposts with friends and speak freely without second guessing if I’m gonna be profiled by a data broker
You are welcome to live your privileged life with your privileged friends using any software you feel is good enough. Just don't assume everyone can afford that luxury.
https://pressgazette.co.uk/news/rsf-moves-downgrades-global-... is a decent index to assess in what kind of country you're living in.
"It's also only decentralized as much as public email infrastructure is decentralized."
That's already a lot more decentralized than most web services we use on a daily basis
In what sense? I think in practice there are significantly fewer widely used email service providers than there are web service providers. If you threw a rock at a crowd of people, you'd probably hit someone with a Gmail or Outlook-managed inbox.
> In what sense?
Email is an open interoperable standard, owned by nobody.
You can run your own email infrastructure just fine (I do, many do).
So it is fundamentally different from all the proprietary walled gardens which have a single owner that controls everything.
All of which is true and praiseworthy.-
Sadly, as with many things, Gmail effectively controls it de facto, nowadays ...
It is not possible to hide the fact that you conversed with a certain person from your service provider. That's part of why being able to choose a service provider is so important.
Theoretically, Cwtch[1] would afford you this obfuscation assuming Tor is secure and your adversary isn't nation-state level.
Similarly, using SimpleX private message routing via .onion message relays and the fact that the system has no identifiers can also afford you that obfuscation.
[1] https://docs.cwtch.im/
Differences between Cwtch, and SimpleX? Which are you leaning towards to and why?
According to https://github.com/simplex-chat/simplexmq/blob/stable/protoc...:
> identify that and when a user is using SimpleX.
Does this apply to Cwtch?
Also, is it not possible to obfsucate this traffic? Tor with obfs4?
Related:
#1 - https://security.stackexchange.com/questions/241730/traffic-...
#2 - https://github.com/simplex-chat/simplex-chat/issues/4300
#3 - https://github.com/tst-race/race-docs/blob/main/race-channel...
> Which are you leaning towards to and why?
Heavily sandboxed SimpleX that's firewalled to block any non-Tor traffic. Chose this one because it allows for offline message sending/receiving, despite privacy implications, and because it has clients people will actually use.
Cwtch doesn't let you send messages when the recipient is offline by virtue of how it works, which is more secure, but inconvenient.
When evaluating Cwtch, I think I read somewhere it might send identifying metadata to your recipient, or something similar, but I might just be making that up. I'll have to look up what I was reading.
> > identify that and when a user is using SimpleX.
> Does this apply to Cwtch?
With Cwtch you're running two hidden services, one on either end of the chat, and that happens over Tor with no middleman service, so no. A passive network observer can tell when you're connecting to Tor, but you can attempt to obfuscate that with transports.
> obfuscate that with transports.
Such as obfs4, I presume.
I read about RACE just now, seems interesting:
- https://github.com/tst-race/race-quickstart?tab=readme-ov-fi...
- https://github.com/tst-race/race-destini
Have you heard about it, or have you used it before?
> Cwtch doesn't let you send messages when the recipient is offline by virtue of how it works, which is more secure, but inconvenient.
I agree. How much more secure is that? In the case of Ricochet, this only applies to friend requests. You have to be online to be able to receive friend requests, which I am fine with.
>How much more secure is that?
It's much more secure wrt metadata. There is no third party server that's able to amass metadata about the two users conversing. SimpleX doesn't hide your IP-address from the server, and given that there's exactly two parent companies hosting ALL of the official servers, it's not too hard for Akamai or https://runonflux.com/ or anyone who compromises their OOBM systems to perform end-to-end correlation between two users.
https://discuss.privacyguides.net/t/simplex-vs-cwtch-who-is-... has a lot of discussion about Simplex vs Cwtch.
Agree with your post, but do want to point out that using private message routing on SimpleX theoretically hides your IP address from the server[1].
Similarly, built-in routing over Tor can make performing correlation attacks difficult for some adversaries, and if you elect to use your own .onion servers instead of the official ones, it adds another layer of obfuscation.
[1] https://github.com/simplex-chat/simplexmq/blob/stable/protoc...
What do you mean by "own .onion servers" here specifically? It is ambiguous for me. Your own hidden service? Your own bridge? As for hidden services, that would be up to SimpleX to do so (just like how Ricochet does it), otherwise I have no idea how one would do it with SimpleX or configure SimpleX to use "mine". You would need Orbot on Android to begin with to use SimpleX with Tor, and I do not know if there is such an option to "use own hidden service", as hidden services do not work this way at all.
How do you configure SimpleX on Android to use your own SMP servers BTW?
> Such as obfs4, I presume.
Yep, but the author of obfs4 says not to use it, there are more modern transports with less flaws.
At the end of the day, the transport lists are public, but sharded, so it's truly just obfuscation no matter what transport protocol you use. Someone observing your connection with the resources to map out transport relays can tell if you're using Tor.
> Have you heard about it, or have you used it before?
I haven't, but it looks interesting. It seems they're doing a similar mixnet approach to SimpleX.
> I agree. How much more secure is that?
If you don't to rely on a third party to queue and relay your messages when your recipient comes online, it's one less party that you're sharing information with.
I also believe it opens you up to Tor correlation attacks, like what happened with Ricochet. Maybe an overlay mixnet can add some further obfuscation, as with SimpleX and RACE, but I assume those overlays are vulnerable to correlation attacks, as well.
> Yep, but the author of obfs4 says not to use it, there are more modern transports with less flaws.
Such as?
Check out https://torproject.github.io/manual/circumvention/ and https://obfuscation.github.io/
I know about those, but scramblesuit and meek and snowflake came before obfs4 I believe and they do not achieve the same thing obfs4 does, so I do not see a better obfs4 alternative here.
> It's also only decentralized as much as public email infrastructure is decentralized.
So… entirely? What am I missing about your point?
I run my own email servers, but 99% of mail goes over Google/Microsoft/AWS/etc email servers anyway.
In practice, it's quite centralized and you're always at risk of one of the big providers locking your servers out of their network or putting you on a blocklist they all use.
Public email infrastructure is almost entirely dominated by Google. This is worth looking into if you’re not familiar with the state of affairs