Delta Chat is a decentralized and secure messenger app(delta.chat)
delta.chat
Delta Chat is a decentralized and secure messenger app
https://delta.chat/en/
200 comments
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.
Because poker variants are so popular basically everything varies, but yes there's often an ante (a forced bet every player makes each round), and that's even present in some Hold 'Em structures.
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.
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.
[deleted]
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/
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
[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.
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.
They don’t seem to think it’s an Autocrypt thing; they seem to think it’s an issue with certificates being de facto append-only. Also, “most” is not acceptable —- if even a small percentage of Signal clients had this kind of FS-breaking bug it’d be considered a significant vulnerability. We should demand better than “most.”
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.
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?
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 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.)
exactly why Signal uses phone numbers
the reason may be the same, but the effect is entirely different. until recently signal did not allow hiding the phone number, failing my privacy expectations. a public phone number is something entirely different than a public email address. signal is also centralized with its own servers. deltachat works completely without dedicated servers. and emails easily allow multiple accounts.
and what are reasonable security expectations? what you and i consider reasonable does not at all match what the general population expects. for most people sending encrypted emails would already be a win. (autocrypt also works with regular email clients, not just deltachat)
the goal here is to raise the general use of encryption in messages. if that is not sufficient then deltachat is not the right tool. but i have friends on telegram and whatsapp. getting them to use deltachat would be an improvement.
the reason may be the same, but the effect is entirely different. until recently signal did not allow hiding the phone number, failing my privacy expectations. a public phone number is something entirely different than a public email address. signal is also centralized with its own servers. deltachat works completely without dedicated servers. and emails easily allow multiple accounts.
and what are reasonable security expectations? what you and i consider reasonable does not at all match what the general population expects. for most people sending encrypted emails would already be a win. (autocrypt also works with regular email clients, not just deltachat)
the goal here is to raise the general use of encryption in messages. if that is not sufficient then deltachat is not the right tool. but i have friends on telegram and whatsapp. getting them to use deltachat would be an improvement.
You are not expected to use your regular email address, you get assigned a random email address that gets tied to your account (and your chosen username, but I think that can be changed) and the servers that store uncollected messages are only accepting properly encrypted emails. All this is completely transparent to users, it looks like Signal, but doesn't require a phone number, and it uses proven technologies where server managers would only have access to the randomized email addresses and the message size and times (but those are not logged in the standard setup).
There is an inbuilt drive for decentralization, as "anybody" could run a server (I just set one up).
There is an inbuilt drive for decentralization, as "anybody" could run a server (I just set one up).
getting a random email address from a dedicated deltachat server is a new, optional feature. it didn't exist when i signed up. no matter. i am not using deltachat in a way that i need to stay anonymous. i am using it to talk to my friends. and if i wanted to i could create another account on the new servers. the ability to use a semi-anonymous email was always there. it's just a matter of finding a server for that. i am afraid though that the anonymity of the deltachat servers will be abused and they become targets of law enforcement.
Centralization is not a security property in the context of E2EE. You can want decentralization (I often do), but it’s essentially an ideological demand rather than a security preference when the server provably has no access to your messages or metadata.
> and what are reasonable security expectations?
End-to-end encryption that the user can’t accidentally downgrade from and that doesn’t spray valuable metadata across the Internet. That’s table stakes; I’m not interested in lowering my standards below that.
> for most people sending encrypted emails would already be a win.
I don’t think this is even remotely true. I think the average person doesn’t know what an encrypted email is. We’re now in at least the third decade of encrypted email techniques, and adoption outside of corporate S/MIME (another can of worms) is marginal.
There’s almost too much to even say here; it’s a disservice to even accept the implicit assumption that users would use encrypted email correctly if they could be made to: the single most common breakage point for all of this stuff is still people replying or forwarding previously encrypted messages in the clear!
> the goal here is to raise the general use of encryption in messages.
No. The goal is security. “General use of encryption” goes back to putting ideology before security. The goal is to actually put users in a position where adversaries struggle to collect the kinds of data and metadata that would allow them to harm people. The US famously kills people based on metadata[1], and we’re the “strict” ones in terms of evidentiary standards.
[1]: https://www.nybooks.com/online/2014/05/10/we-kill-people-bas...
> and what are reasonable security expectations?
End-to-end encryption that the user can’t accidentally downgrade from and that doesn’t spray valuable metadata across the Internet. That’s table stakes; I’m not interested in lowering my standards below that.
> for most people sending encrypted emails would already be a win.
I don’t think this is even remotely true. I think the average person doesn’t know what an encrypted email is. We’re now in at least the third decade of encrypted email techniques, and adoption outside of corporate S/MIME (another can of worms) is marginal.
There’s almost too much to even say here; it’s a disservice to even accept the implicit assumption that users would use encrypted email correctly if they could be made to: the single most common breakage point for all of this stuff is still people replying or forwarding previously encrypted messages in the clear!
> the goal here is to raise the general use of encryption in messages.
No. The goal is security. “General use of encryption” goes back to putting ideology before security. The goal is to actually put users in a position where adversaries struggle to collect the kinds of data and metadata that would allow them to harm people. The US famously kills people based on metadata[1], and we’re the “strict” ones in terms of evidentiary standards.
[1]: https://www.nybooks.com/online/2014/05/10/we-kill-people-bas...
Centralization is not a security property
true, i wasn't thinking about security here but reuse of infrastructure. signal doesn't reuse infrastructure because it needs its own servers.
End-to-end encryption that the user can’t accidentally downgrade from
that's a fair point.
that doesn’t spray valuable metadata across the Internet
i find that a gross exaggeration. yes. metadata can be read by every server the mail passes through. but in practice most mails are only touching the sending and the receiving mail server. if both of those servers are in control of the sender and recipient and the connection between them is encrypted then the metadata remains private.
also, where i use deltachat, the alternative is to use email.
I think the average person doesn’t know what an encrypted email is
which is why we need more encryption by default.
adoption outside of corporate S/MIME is marginal.
because it is to hard to use. deltachat makes it easy to use. next possible step: delta mail. a more traditional mail client that makes encryption as easy as deltachat does.
The goal is to actually put users in a position where adversaries struggle to collect the kinds of data and metadata that would allow them to harm people
there is a long road to get to that. more encryption is just one step, but a necessary one. i agree with you, but the goal can't be reached if we don't work on multiple fronts. one of those is helping people to learn about encryption and privacy, which only happens by slowly getting them to use better tools and by improving those tools.
rejecting deltachat is rejecting something that improves the current state for something better that is not obtainable by some. sometimes that makes sense, especially if the solution promises more than it holds. and deltachat would fall into this if it were to promise complete privacy. but i don't think it does that.
i have friends who outright refuse to sign up to a new service. but deltachat is ok because they can use their existing email for it. technically that sounds the same as saying that with signal you can reuse your existing phonenumber, but people already have much higher privacy expectations to sharing their phone number, and also deltachat doesn't share your email address except with recipients so it really isn't the same thing.
true, i wasn't thinking about security here but reuse of infrastructure. signal doesn't reuse infrastructure because it needs its own servers.
End-to-end encryption that the user can’t accidentally downgrade from
that's a fair point.
that doesn’t spray valuable metadata across the Internet
i find that a gross exaggeration. yes. metadata can be read by every server the mail passes through. but in practice most mails are only touching the sending and the receiving mail server. if both of those servers are in control of the sender and recipient and the connection between them is encrypted then the metadata remains private.
also, where i use deltachat, the alternative is to use email.
I think the average person doesn’t know what an encrypted email is
which is why we need more encryption by default.
adoption outside of corporate S/MIME is marginal.
because it is to hard to use. deltachat makes it easy to use. next possible step: delta mail. a more traditional mail client that makes encryption as easy as deltachat does.
The goal is to actually put users in a position where adversaries struggle to collect the kinds of data and metadata that would allow them to harm people
there is a long road to get to that. more encryption is just one step, but a necessary one. i agree with you, but the goal can't be reached if we don't work on multiple fronts. one of those is helping people to learn about encryption and privacy, which only happens by slowly getting them to use better tools and by improving those tools.
rejecting deltachat is rejecting something that improves the current state for something better that is not obtainable by some. sometimes that makes sense, especially if the solution promises more than it holds. and deltachat would fall into this if it were to promise complete privacy. but i don't think it does that.
i have friends who outright refuse to sign up to a new service. but deltachat is ok because they can use their existing email for it. technically that sounds the same as saying that with signal you can reuse your existing phonenumber, but people already have much higher privacy expectations to sharing their phone number, and also deltachat doesn't share your email address except with recipients so it really isn't the same thing.
> if both of those servers are in control of the sender and recipient and the connection between them is encrypted then the metadata remains private.
Why are we entertaining this hypothetical? It isn’t true in practice; the average user doesn’t control their mail server. The average user is using Gmail or Outlook, where their metadata is a single subpoena away.
And again, it just isn’t true: you need not just control over the server but also strict transport security for this property. This is not widely true of mail servers on the Internet.
> rejecting deltachat is rejecting something that improves the current state for something better that is not obtainable by some.
I don’t agree. I think the average user has multiple high-quality E2EE messaging technologies available to them, and that Delta Chat effectively muddies the water by providing a worse security posture with the trappings of a familiar-but-unsecurable ecosystem (email).
(I also don’t know why people think Signal shares your phone number with people other than recipients. To my knowledge, that has never been the default and presumably never will be, even with their private contact discovery protocol.)
Why are we entertaining this hypothetical? It isn’t true in practice; the average user doesn’t control their mail server. The average user is using Gmail or Outlook, where their metadata is a single subpoena away.
And again, it just isn’t true: you need not just control over the server but also strict transport security for this property. This is not widely true of mail servers on the Internet.
> rejecting deltachat is rejecting something that improves the current state for something better that is not obtainable by some.
I don’t agree. I think the average user has multiple high-quality E2EE messaging technologies available to them, and that Delta Chat effectively muddies the water by providing a worse security posture with the trappings of a familiar-but-unsecurable ecosystem (email).
(I also don’t know why people think Signal shares your phone number with people other than recipients. To my knowledge, that has never been the default and presumably never will be, even with their private contact discovery protocol.)
> 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.
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.
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.
This conversation is important, and weighing these aspects against each other is critical in order to form better opinions. We clearly both agree there are subtle and counter-intuitive effects at play. I don't think there's anything wrong with debating them, and I'm happy to be convinced otherwise.
> Unless your messenger is at pains to make sure people don't use it in life-or-death situations [...] the exact opposite thing is true
Right, this is the false-sense-of-security effect. It exists and it's real. But there are more aspects that weigh in.
> People always have a third option: not sending the message electronically.
I challenge this assumption. In reality the effect is not about what they can do if they listen to the advice of Bruce Schneier, but what they will do. Navel-gazing on security and throwing your hands up if people don't act "the way they should" is what's really irresponsible, imo. I.e. if your contacts are not physically close, they won't (or even can't) schedule a flight to send a message. They'll generally use what's socially convenient, even if they're discussing something like abortion in an oppressive state. If you're lucky non-techies will say "Hey, maybe we should try that app Signal, I heard it's more secure". That's as good of a win as it gets.
The counter-example would be going around saying Signal is worthless because they collect phone numbers, they don't enforce public key validation, and they don't use onion routing to protect your social graph. I don't think we disagree about how ridiculous that would be, even if we disagree on which aspects are most important.
Basically, if set the weight of all security properties to ∞, you will get something that's so wildly inconvenient that nobody would use it. Even PGP that's relatively easy to use was at its peak about as popular as starting a yak farm.
> Unless your messenger is at pains to make sure people don't use it in life-or-death situations [...] the exact opposite thing is true
Right, this is the false-sense-of-security effect. It exists and it's real. But there are more aspects that weigh in.
> People always have a third option: not sending the message electronically.
I challenge this assumption. In reality the effect is not about what they can do if they listen to the advice of Bruce Schneier, but what they will do. Navel-gazing on security and throwing your hands up if people don't act "the way they should" is what's really irresponsible, imo. I.e. if your contacts are not physically close, they won't (or even can't) schedule a flight to send a message. They'll generally use what's socially convenient, even if they're discussing something like abortion in an oppressive state. If you're lucky non-techies will say "Hey, maybe we should try that app Signal, I heard it's more secure". That's as good of a win as it gets.
The counter-example would be going around saying Signal is worthless because they collect phone numbers, they don't enforce public key validation, and they don't use onion routing to protect your social graph. I don't think we disagree about how ridiculous that would be, even if we disagree on which aspects are most important.
Basically, if set the weight of all security properties to ∞, you will get something that's so wildly inconvenient that nobody would use it. Even PGP that's relatively easy to use was at its peak about as popular as starting a yak farm.
> I challenge this assumption. In reality the effect is not about what they can do if they listen to the advice of Bruce Schneier, but what they will do. Navel-gazing on security and throwing your hands up if people don't act "the way they should" is what's really irresponsible, imo. I.e. if your contacts are not physically close, they won't (or even can't) schedule a flight to send a message. They'll generally use what's socially convenient, even if they're discussing something like abortion in an oppressive state. If you're lucky non-techies will say "Hey, maybe we should try that app Signal, I heard it's more secure". That's as good of a win as it gets.
I disagree, people will end up in prison or dead if they let a false sense of security compromise themselves. It should be stressed that certain sensitive activities should not involve computers, phones, etc because of the very real possibility of dire consequences. If someone is desperate enough where they have to resort to using computers to do sensitive activities, they should be given the best advice, caveats emphasized, and not just what someone feels is "good enough".
I disagree, people will end up in prison or dead if they let a false sense of security compromise themselves. It should be stressed that certain sensitive activities should not involve computers, phones, etc because of the very real possibility of dire consequences. If someone is desperate enough where they have to resort to using computers to do sensitive activities, they should be given the best advice, caveats emphasized, and not just what someone feels is "good enough".
Advising people to use messaging systems that you know to be faulty because they optimize in some other non-personal-safety area like "federation" or "open standards" or "compatibility with email" means that you are putting your own aesthetic preferences above other people's safety. It's simply malpractice.
I really think people would be safer communicating their sensitive messages on Delta Chat than on Signal. Both are encrypted securely enough, and the endpoints being compromised is probably the biggest threat in both cases, but with Signal there is more metadata (the phone number) and you're almost certain this is being farmed on a massive scale (as opposed to Delta Chat).
Wildly false. This is the problem with advice for activists and at-risk people; there's no way to distinguish the stuff that is just nerd LARPing from the stuff that is actually based on educated risk analysis.
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.
> 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.
> 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.
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.
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.
I agree from that perspective.
> but if you need to keep your identity, social graph and the fact that you conversed with certain people obfuscated
Does Signal, the current "privacy respecting, secure default" for mainstream people, provide this?
Does Signal, the current "privacy respecting, secure default" for mainstream people, provide this?
"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
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.
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.
Signal is notably not proprietary. And email is de-facto owned by a small handful of service providers.
Telling Joe Shmoe that he should run his own email infrastructure instead of using literally anything actually built for E2EE is an ideological argument, not one grounded in Joe’s message security expectations.
Telling Joe Shmoe that he should run his own email infrastructure instead of using literally anything actually built for E2EE is an ideological argument, not one grounded in Joe’s message security expectations.
> Signal is notably not proprietary.
See parallel response. Open source is not the same as an open interoperable standard.
> And email is de-facto owned by a small handful of service providers.
No, not really. Yes there are large providers who manage a lot of people, but it is not owned by anyone.
> Telling Joe Shmoe that he should run his own email infrastructure
That's not necessary either. Joe can get his email from any of thousands of providers ranging from large to tiny if he doesn't want to run it. Service can also be delegated in various ways depending on comfort and convenience. For instance, one mixed setup is to manage receiving by one provider (which could be oneself, to guarantee you can't get locked out) and delegating sending to a different provider (self or others).
It's also easy to delegate to a tech-savvy friend or family member. I run email for my own domains but also for most family members and a few consulting businesses in our circle.
This is the power of open standards codified in RFCs. It is what the Internet was meant to be. Walled gardens was never part of the plan.
See parallel response. Open source is not the same as an open interoperable standard.
> And email is de-facto owned by a small handful of service providers.
No, not really. Yes there are large providers who manage a lot of people, but it is not owned by anyone.
> Telling Joe Shmoe that he should run his own email infrastructure
That's not necessary either. Joe can get his email from any of thousands of providers ranging from large to tiny if he doesn't want to run it. Service can also be delegated in various ways depending on comfort and convenience. For instance, one mixed setup is to manage receiving by one provider (which could be oneself, to guarantee you can't get locked out) and delegating sending to a different provider (self or others).
It's also easy to delegate to a tech-savvy friend or family member. I run email for my own domains but also for most family members and a few consulting businesses in our circle.
This is the power of open standards codified in RFCs. It is what the Internet was meant to be. Walled gardens was never part of the plan.
All of which is true and praiseworthy.-
Sadly, as with many things, Gmail effectively controls it de facto, nowadays ...
Sadly, as with many things, Gmail effectively controls it de facto, nowadays ...
The Delta Chat ecosystem runs on systems that only accept encrypted emails. You access it through a Delta Chat client, you don't use a Gmail or Outlook-managed inbox.
people exist that run their own mailserver
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/
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...
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.
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.
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.
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...
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?
How do you configure SimpleX on Android to use your own SMP servers BTW?
By "your" I mean your chosen 3rd party servers
Could you clarify with regarding to .onion? How would I set this up for SimpleX and how would I configure SimpleX to use it, on, say, Android and Linux? I believe to use Tor with SimpleX, you would have to use Orbot, for example. What would I have to set up and how, on Linux? Genuine question. I would much prefer to self-host it.
I would also like to know how I would configure SimpleX on Android to use my own SMP servers.
Edit: I found this: https://simplex.chat/docs/server.html.
And I found:
I would also like to know how I would configure SimpleX on Android to use my own SMP servers.
Edit: I found this: https://simplex.chat/docs/server.html.
And I found:
# `socks_mode` can be 'onion' for SOCKS proxy to be used for .onion destination hosts only (default)
# or 'always' to be used for all destination hosts (can be used if it is an .onion server).
# socks_mode: onion
Yeah, I figured it out. I think I am supposed to do this: run a hidden service and a SimpleX server that uses the hidden service's port, and then use the hidden service's hostname as my SMP server that I set within the app.
On Android, however, this is not as easy or straightforward and I cannot think of a way to do this, to be honest. That is why I prefer these programs to have Tor bundled and run the hidden service by themselves with a hardened-enough torrc. Ricochet does this on desktop, which I think is the right way to go about this. SimpleX's server (https://github.com/simplex-chat/simplexmq) should do this.
On Android, however, this is not as easy or straightforward and I cannot think of a way to do this, to be honest. That is why I prefer these programs to have Tor bundled and run the hidden service by themselves with a hardened-enough torrc. Ricochet does this on desktop, which I think is the right way to go about this. SimpleX's server (https://github.com/simplex-chat/simplexmq) should do this.
From the SimpleX doc you linked
"To mitigate this problem SimpleX Messaging Protocol servers support 2-hop onion message routing when the SMP server chosen by the sender forwards the messages to the servers chosen by the recipients, thus protecting both the senders IP addresses and sessions, even if connection isolation and Tor are not used."
The thing is, like I said, there are only two main companies running all the servers. Akamai and RunOnFlux. So unless Tor is used, it's a 50-50 chance that both users are connecting on to servers run by Akamai. Doesn't matter if the two servers don't share with each other the information about the IP-adderss of the user's peer. It's enough the parent VPS company has access to all traffic coming into the infrastructure. There's nothing "onion" about that routing. It's much closer to just traffic between two nodes of a server farm. Which is what practically any scalable IM server does.
"To mitigate this problem SimpleX Messaging Protocol servers support 2-hop onion message routing when the SMP server chosen by the sender forwards the messages to the servers chosen by the recipients, thus protecting both the senders IP addresses and sessions, even if connection isolation and Tor are not used."
The thing is, like I said, there are only two main companies running all the servers. Akamai and RunOnFlux. So unless Tor is used, it's a 50-50 chance that both users are connecting on to servers run by Akamai. Doesn't matter if the two servers don't share with each other the information about the IP-adderss of the user's peer. It's enough the parent VPS company has access to all traffic coming into the infrastructure. There's nothing "onion" about that routing. It's much closer to just traffic between two nodes of a server farm. Which is what practically any scalable IM server does.
> 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.
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?
Such as?
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.
Definitely not for threat models where anonymity is critical
> It's also only decentralized as much as public email infrastructure is decentralized.
So… entirely? What am I missing about your point?
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.
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
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
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
I wonder why this was downvoted
"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.
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.)
(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.
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.
> fully open source including the server side
But, and maybe I'm stating the obvious but it is a critical difference, open source is nice but much inferior to open interoperable standards.
Signal-the-company does not allow any clients other than their proprietary compiled client (I believe they sort of tolerate some, but not supported). So while in theory I could use the open source software to run my parallel signal-protocol network, it won't interoperate with the one run by Signal-the-company which is where most people are. So, not actually useful.
Contrast this with email which is an open standard. I can run any SMTP server I like and any MUA I like (or even write my own for one or both), and interoperate with the whole universe of people who use email.
But, and maybe I'm stating the obvious but it is a critical difference, open source is nice but much inferior to open interoperable standards.
Signal-the-company does not allow any clients other than their proprietary compiled client (I believe they sort of tolerate some, but not supported). So while in theory I could use the open source software to run my parallel signal-protocol network, it won't interoperate with the one run by Signal-the-company which is where most people are. So, not actually useful.
Contrast this with email which is an open standard. I can run any SMTP server I like and any MUA I like (or even write my own for one or both), and interoperate with the whole universe of people who use email.
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.)
(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.
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.
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.
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.
"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.
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.
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.
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.
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.
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.
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:
https://support.delta.chat/t/autocrypt-key-rotation/2936
https://support.delta.chat/t/autocrypt-key-rotation/2936
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?
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...
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.
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.
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://www.0xchat.com/
Private key login, encrypted private chats and contacts, encrypted group chats, and lightning payments. Decentralised, built on Nostr. Available on all platforms.
https://www.0xchat.com/
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.
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.
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.
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.
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 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.
>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.
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 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.
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.
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.
The closer you move to the user, the more the threat of creepy buddy watching over metadata of people they know grows.
actually i don't follow that argument. it is more likely that my data gets caught up with someone accessing a larger server than my own server. if someone targets my own server they may as well target all my messaging clients and get all the data from there.
actually i don't follow that argument. it is more likely that my data gets caught up with someone accessing a larger server than my own server. if someone targets my own server they may as well target all my messaging clients and get all the data from there.
The thing is, if there's three users that know each other, using one server run by one of the three, then by definition there is one person with access to metadata of the 1:1 conversation between the two other users. If you are the one running the server, then your buddies are taking the risk that you're the creepy buddy.
The proper way to address this is with p2p messaging, like Cwtch, where each user is running server for their own account. Cwtch also experimentally supports caching ciphertexts on a server that's hosting the group chats that all members will have access to anyway, so there's no peer metadata to eavesdrop on.
The proper way to address this is with p2p messaging, like Cwtch, where each user is running server for their own account. Cwtch also experimentally supports caching ciphertexts on a server that's hosting the group chats that all members will have access to anyway, so there's no peer metadata to eavesdrop on.
well, that depends on your threat model. for me, an acquaintance finding out who i am talking to isn't a threat. a threat is profiling by big companies. and already by either running my own server or using a smaller paid email service, that threat is drastically reduced.
in fact this particular threat that you describe is more likely to happen at a university server where a rogue admin may use their privilege to snoop on people they want to stalk for whatever reason, as opposed to the friend that i chose because i trust them, like say the admin of the server of the local linux user group or the hackerspace that i am a member of.
in fact i am more likely to trust anyone that i know in person, simply because even if that person decides to snoop on me we can work that our in person, and the likely hood for it happening is low because it would affect our friendship. and i would guess that this is true for most people.
at some point you have to trust someone, and the closer you are to that person, the easier it will be to resolve problems.
in fact this particular threat that you describe is more likely to happen at a university server where a rogue admin may use their privilege to snoop on people they want to stalk for whatever reason, as opposed to the friend that i chose because i trust them, like say the admin of the server of the local linux user group or the hackerspace that i am a member of.
in fact i am more likely to trust anyone that i know in person, simply because even if that person decides to snoop on me we can work that our in person, and the likely hood for it happening is low because it would affect our friendship. and i would guess that this is true for most people.
at some point you have to trust someone, and the closer you are to that person, the easier it will be to resolve problems.
That stalking thing also happens in personal peer networks. For the messaging app to have any relevance, you're going to want most of your peers in and once there's a few hundred people in, there's power to be abused.
University students don't get to run infrastructure of the facility, and at least in my uni, the old beard IT staff members and faculty don't really hang out with the students aside course environments or support groups, so there's a bigger gap. There's also salaries and careers in the line.
But bickering about who's trustworthy is pointless when there's trustless architectures for those situations already.
University students don't get to run infrastructure of the facility, and at least in my uni, the old beard IT staff members and faculty don't really hang out with the students aside course environments or support groups, so there's a bigger gap. There's also salaries and careers in the line.
But bickering about who's trustworthy is pointless when there's trustless architectures for those situations already.
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?
Anyone up to the challenge?
being able to use a telegram client for matrix would be great, but the problem with matrix is not so much the UI but the complex handling of encryption which can sometimes fail. unlike deltachat which downgrades on failure, which is bad, matrix stops working on failure, which for the average user is worse. a better UI won't fix that unfortunately.
still i like the idea. but deltachat also has a nice UI, and for matrix i use fluffychat which is also quite nice.
still i like the idea. but deltachat also has a nice UI, and for matrix i use fluffychat which is also quite nice.
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
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.
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.
[1] https://ron.stoner.com/nostr_Security_and_Privacy/
> 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.
[1] https://ron.stoner.com/nostr_Security_and_Privacy/
The analogy works in the visibility sense and I see why you might assume there’s a blockchain involved in Nostr. But to clarify, there is not.
It’s worth highlighting as there are many affinity scammers spinning up tokens/blockchains called “Nostr”.
It’s worth highlighting as there are many affinity scammers spinning up tokens/blockchains called “Nostr”.
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).
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?
But - has there been security audit been done?
Is it just me or does the website render poorly on mobile?
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.
1. https://ems.element.io/tools/matrix-migration
2. https://arewep2pyet.com/
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.
1. https://ems.element.io/tools/matrix-migration
2. https://arewep2pyet.com/
agreed, lack of account portability in Matrix is a pain. we’re working on it in msc4014 and I expect to see some progress this year.
It's great to see important questions being raised around encryption defaults, metadata, user trust, and the broader push toward decentralized, user-controlled messaging - things we at gospl.chat think about every day. We salute projects like Delta Chat that get more people thinking about privacy and building tools that are both easy to use and secure by design. Cheers!
For FOSS software, why not have a link to the Github repo or org prominently displayed in the title/menu bar?
It took me a couple of clicks to find: https://github.com/deltachat
The "Internet Standards" link points to a URL under https://github.com/deltachat/deltachat-core-rust/ but when you go there it actually redirects and you end up at https://github.com/chatmail/core which is also confusing.
It took me a couple of clicks to find: https://github.com/deltachat
The "Internet Standards" link points to a URL under https://github.com/deltachat/deltachat-core-rust/ but when you go there it actually redirects and you end up at https://github.com/chatmail/core which is also confusing.
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.)
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.
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.)
[1]: https://signal.org/blog/private-contact-discovery/
(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.)
[1]: https://signal.org/blog/private-contact-discovery/
> 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...
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...
[deleted]
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.
I somehow agree with your analogy and not your conclusion? SSLv3 is what gave us TLS1.3
The OpenPGP crypto can never be "outdated" because it is constantly being updated.
The OpenPGP crypto can never be "outdated" because it is constantly being updated.
> I somehow agree with your analogy and not your conclusion? SSLv3 is what gave us TLS1.3
There's no PGP equivalent of TLSv1.3. The last time people tried that it created a huge drama.
> The OpenPGP crypto can never be "outdated" because it is constantly being updated.
Yet it hasn't been, it's not there in the implementations, it's not there in the defaults.
There's no PGP equivalent of TLSv1.3. The last time people tried that it created a huge drama.
> The OpenPGP crypto can never be "outdated" because it is constantly being updated.
Yet it hasn't been, it's not there in the implementations, it's not there in the defaults.
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.
My findings:
> I’ve tested Delta Chat with my own mail server, which uses Postfix and has everything configured for public e-mail, like DKIM signing, spamd, IP blocklist checks and so on, and each message took about 2 seconds from one device to another. Using a public server it sure feels below 300ms, so there is room for improvement when self-hosting a dedicated chatserver.
https://www.kassner.com.br/en/2025/05/08/delta-chat-encrypte...
In my test, both clients were ~80ms away from the IMAP server, but the server was delivering to itself. I’m also not sure if the port 587 has an idle/keepalive mechanism, or if it has to go around the entire TLS handshake at each message.
I don’t think 2 seconds is bad, most of my contacts will take at least triple that to read and type in an answer, so not a big deal.
> I’ve tested Delta Chat with my own mail server, which uses Postfix and has everything configured for public e-mail, like DKIM signing, spamd, IP blocklist checks and so on, and each message took about 2 seconds from one device to another. Using a public server it sure feels below 300ms, so there is room for improvement when self-hosting a dedicated chatserver.
https://www.kassner.com.br/en/2025/05/08/delta-chat-encrypte...
In my test, both clients were ~80ms away from the IMAP server, but the server was delivering to itself. I’m also not sure if the port 587 has an idle/keepalive mechanism, or if it has to go around the entire TLS handshake at each message.
I don’t think 2 seconds is bad, most of my contacts will take at least triple that to read and type in an answer, so not a big deal.
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.
> 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)
Anyone else immediately think of delta airlines? I was excited to read an analysis of a seat-to-seat chat implementation
[email protected] slaps [email protected] 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.
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 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.
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.
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.
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.
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.
So I would say it's a low priority feature in the backlog.
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).
Or at least via a proxy.
So contact invitation can just be handled with use-once codes (or at least trivially burnable ones).
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.
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...
[^3]: https://f-droid.org/en/packages/spam.blocker/
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...
[^3]: https://f-droid.org/en/packages/spam.blocker/
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
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.
Bluestein(2)
Has anyone used that with their Protonmail account?
Maybe something Proton should build on for its own chat app.
Maybe something Proton should build on for its own chat app.
DeltaChat is incompatible with ProtonMail:
https://providers.delta.chat/protonmail
https://providers.delta.chat/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
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.
https://briarproject.org/
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.
https://briarproject.org/
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.
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.
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.
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?
Which party the developer associated with? Hopefully not CIA.
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
Maybe with AI there could be a sort of decentralized antispam filtering . but maybe not
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?
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
— https://delta.chat/en/help#security-audits
Their FAQ answers this:
> Yes, multiple times. The Delta Chat project continuously undergoes independent security audits and analysis
— https://delta.chat/en/help#security-audits
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. :(
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.
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.
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 :)
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 :)
Yes, I think the deltachat people should have gone with a different (still open source of course) encryption method that supports forward secrecy, and not try to be compatible with encrypted emailing. You can still use the email server/client infrastructure, but don't try to serve "normal" emails on the same system, and don't allow normal email providers to take part.
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.