Compare to most IM systems Delta Chat is:
- easier to set up: you already have an email
- equally private: most IM systems leak metadata anyways. A global observer can infer your peers.
- compared to Signal, it does not snoop your phone number
- cheaper to run 1: managing mailservers is cheaper than managing both mailservers and IM servers
- cheaper to run 2: mailservers evolved for decades and are now pretty efficient, especially compared to most IM servers
Seriously, WTF? It's none of your business what device I use and whether it's virtual or not.
I got a cease-and-desist from Facebook many years ago for trying to write a Perl interface to their messenger.
I own and control my devices, damnit. I hate these walled garden messaging apps that seem to actively thwart innovation. All I want is a protocol (which I'm even happy to pay for!) and I will decide how messages present themselves on my end.
Many years ago I used Pidgin to interface to MSN, ICQ, AIM, QQ, Gtalk, Yahoo, Zephyr, and a couple others. It was great -- I had E2E encryption (sorry Pichai and Whatsapp I had E2E encryption on ALL of my messengers before you all decided to wall-garden your apps and then do some stupid PR stunt about E2E encryption years later), automatic human language translation, automatic LaTeX rendering, and a bunch of other features, all of which I don't have now because the messenger apps everyone uses now are anti-innovation. We've taken a huge step backward.
Using a third-party client is a bannable offense under the terms of service. I hate the little "emoticon" icons that are all over the place. It set itself to auto-start on boot (this behavior may be different on win/mac). I don't like trusting it with my messages. It tries to show what applications users are running at the moment. There have been some improvements, but I still don't trust the security of electron.
These are some of the ones I can remember off the top of my head. Generally, it always seemed like it was both trying to baby me and seem "cool". It's many of the things I hate in modern software in one application. It's a chat app, which should shut up and show me messages, not try to double as a social network. It's also a voice conferencing app, which should shut up and transmit/receive audio, not try to double as a social network.
I know a lot of other people who seem to like it as well; good for y'all. All of this would be much less offensive if it hadn't banned me for opting out of its webshit.
I'm going to assume you ask this question because you're honestly curious about GP's discontent with Discord's interface, so this is NOT directed at you, but ...
One of the things I've often noticed is that people like to shame me for being discontent with e.g. WeChat's interface or Facebook's interface. "What's wrong with it? I think it's great! [... and you're weird]" and that mentality of casting away hacker types who want to invent their own UIs is extremely toxic to creativity and innovation, but it's a pattern I've seen happen very frequently with all of these walled-garden apps. (Again this is not directed at you)
I could not see any discussion of the deficiencies of OTR in the titles of the OTRv4 sections. Could someone direct me to a reference? This is the first I have heard of this. I thought OTRv4 was all about usability.
Great, leaking the user's email address which, more often than not, contains their real name is so much better. /s
Seriously, though, I don't think this comparison accurately reflects the differences between Delta Chat and Signal:
Signal uses your phone number for account lookup but not for addressing participants. Moreover, it uses a feature called Sealed Sender to conceal even the cryptographic address of a message's author. In contrast, Delta Chat leaks the email addresses of the people participating in a [group] conversation (and, thus, their social network) not just to one provider (as in the case of Signal) but to all email providers involved in hosting the conversation, meaning that, as a user, you have to trust not just a single but multiple entities. Meanwhile, Signal doesn't even know how many people there are in a group conversation.
I don't disagree but OP was specifically talking about Signal "snooping" one's phone number, so I was talking about a different attack vector.
Besides, to answer all those comments saying that they would set up a separate anonymous email address in heartbeat, we should not forget that the HN crowd is a rather unique group of people. How many of our grandmas would get themselves a new email address just for the purpose of signing up for Signal?
> Signal doesn't seem to care
doesn't seem to be true. The Signal developers have been working on switching from phone numbers to usernames as unique identifiers since at least 2019. As they have mentioned multiple times, though, it is a complicated change.
Are you sure you're not extrapolating from your needs to that of "most people"?
I don't doubt that there are people for who need anonymous communication (whether just sender-anonymous or sender-anonymous, recipient-pseudonymous). But so far, I've never had the need for it.
Quite the opposite, actually: I wouldn't want to receive anonymous messages on Signal, at least not without opt-in.
So, first, to address this: it is frankly extremely rare to have a realistic attacker model that cares about eorher governments or a chosen large corporation having access to your chats, at least "in the West". Like, seriously: sit down and list who you think falls into this category... this is a list which starts with "political dissidents" and continues into some really strange low-likelihood scenarios, as the entire premise surrounds a government or law enforcement agency subpoenaing your messages.
Most of the people I know who are in this category are simply people who want to believe they will one day be targeted by governments for being too dangerous. I can still motivate this software for people, based mostly on scenarios involving bad people getting jobs at large companies to access your information (this is a big issue with Facebook), but even those scenarios barely work against companies like Google (which have good internal information controls). I have gone into this in more detail before (with someone shilling Signal who hilariously ended up just admitting that Signal doesn't work here as it is a "privacy issue").
The ironic thing is that, without also solving the untrusted contact problem, this set barely even includes political dissidents: I have tons of friends who do stuff like coordinate protests, and the #1 realistic concern is that the police--whom I also talk to a lot (I am an elected government official), and I know they do this--have managed to infiltrate their giant group chat and are just watching it all happen and writing down phone numbers. There is a big gap between anonymous and trusted, and it is where most use cases actually happen.
So, on the other side, pretty much every "normal" person constantly meets people with whom they want to communicate without giving away their real phone number / email address. How do I know this? Because that's what most people want to talk with the people whom they are casually dating. This is a big reason why everyone uses Snapchat for almost everything (and Instagram or TikTok for everything else): because it gives you a feeling of control over what people know about you.
Just earlier today I was watching someone on TikTok--in a video about dating communication--say "using Snapchat as the only form of communication during the talking stage is the move: I'm not giving you my phone number... we just met! I would sooner give you a urine sample" (this is an exact quote). The comments mostly agreed with everything she said (and she only had like three supposedly-"unpopular" opinions that were actually quite popular ;P); here are some of the strongest comments about the Snapchat mention.
> Yes! Snapchat! The only way they can’t use one type of social media to find you on other social media
> Yes about the snap vs phone number. I started online dating after a 15 yr relationship and I got a phone stalker that texts me with new numbers
> yeah idk why ppl hate on snap. I prefer it bc they don't have my last name or extra info on me and I can see more what they look like beyond a few pix
Were there people who disagreed with her? Sure, but they were all either advocating for refusing to leave the dating app in the first place (which is itself a trusted provider protecting you from untrustable contacts), were advocating for a different but similar solutions (that still don't involve giving out your phone number), or seriously said "I don't know if I am just old or what"... to which I will note "yes, you are apparently quite old :/".
> Snapchat is dead there are apps like Text+ that create burner numbers...that’s what I use
> Yeah you’re right about this but the Snapchat thing is enlightening as somebody who was an adult before Snapchat lol
So, how good is your spam filter for SMS/calls? /s
Personally, I rather give my mailaddress than my phone number. I can set up a new address rather quick. I cannot switch my phone number that effortless.
In the European countries that I've had phone numbers in, these basically don't exist, and my phone number has been part of several data breaches. (That said, I am curious if this is a problem occurring in almost all or almost no other countries!)
As far as I understand, these problems are also in the process of being fixed in the US via caller ID authentication (to enable carrier-level filtering), which seems like the right approach: In the long term, it's more or less futile to keep a phone number out of data breaches or advertiser databases.
not my experience.
had a phone number in an recent whois record (because reasons) boom wave of spam calls lasting for weeks (germany).
Thankfully getting unlimited anonymous phone numbers easy and free /s
Unlike unlimited anonymous email addresses /s
The app was naturally registered with the custom file extension, so that clicking the email attachment in the Mail app would simply open the app and the message it contained.
Very simple. Very effective. And using an existing and secure (one would hope!) transport: email.
> secure (one would hope!) transport: email.
The best strategy is to assume it is not (because it is not) and implement security at the end, like you did, because you have a specific usage that may not be generalized. End-to-end principle.
If you fetch mails via pop3 be aware, you'll move them away before DeltaChat can move them into its own folder via IMAP to build its message threads. If you're doing IMAP only you'll see the messages with your mailclient unless moved. Maybe consider using a dedicated email-alias or account. If the receiving SMTP on submission doesn't strip your connecting IP Address in the Received headers this is quiet a lot on the wire that DC can't do anything about and where you would rely on transport encryption.
It made a point what a thoughtful chat-view, pgp-using email client can do, so I still recommend to give it a try.
Email is decentralized (at least when not everybody is using Gmail) and isn't a silo like WhatsApp, Signal, Telegram and Threema. Because what happens when Signal goes bad? Everyone has to move again...
Also, Signal's desktop app shouldn't require a stupid phone app to enable it. I have a big powerful setup on my desk and you're asking me to go around my house looking for a silly 6" device to give it permission to log in? That's backwards. It should be the other way around if anything.
For one line "How about lunch today?" messages, it just hurts my engineer bones to use Delta-Chat on a regular email server.
And it's plain text, so storage is not even a problem, it's easily compressed!
Now, don't let me compare 1kB data download to visiting a website and all the crapload i download for the simplest webpage nowadays...
I’m not even saying “there must be a better way” - it is quite possible that there isn’t given the politics involved and the incumbents. Delta is usable, today, with everyone; no need for buy in from your addressees.
But, it still hurts.
1. Of course your mail provider needs to have IMAP enabled (some corporate outlook/exchange installations do not).
2. It could be a problem if you mail provider has a limit on maximum mails per day. I've not experienced that problem, but still..
WhatsApp and Signal allow you to place audio and video calls, Delta Chat (by design) can't. And that's critical for folks who have families and friends in other countries.
In a way, they're almost all reincarnations of what email, IRC or XMPP could already do, with a few makeup changes, often designed to lock-in the user and consequently fragment the user base.
What we need is perhaps more clients, with different interfaces but using the proven underlying protocols and implementing new features client side. Delta Chat, making use of email, does this, with the added bonus of SMTP's natural decentralisation and openness.
With e-mail you can even chat with people who don't have the chat app. Maybe we need an XMPP e-mail bridge ;-)
Btw, when I click "open source" link on delta chat website, I may be not the only one expecting to be taken to the source repository instead of definition of what open source is. I found the actual link, just a suggestion.
Or maybe we need something like Delta Chat that uses XMPP by default but falls back to email if the recipient doesn't have an XMPP account.
It arguably can't be used securely. One of the prominent security researchers on HN actually wrote an article that promising E2EE for email is more harmful than helpful because it gives a false sense of security.
And then if you do decide that whatever encryption scheme you've chosen is right for you, there's no guarantee any significant mass of people supports it.
In short, email security is a bolt-on, and it will never be part of the standard itself.
By that definition, almost every chat app is centralized, especially if you include the step of downloading it over HTTPS. In any case, it would be possible to further enhance email using something like SMTorP so that .onion addresses are used instead.
> And then if you do decide that whatever encryption scheme you've chosen is right for you, there's no guarantee any significant mass of people supports it.
The same is true of any system which is proposed as an alternative to email. Admittedly it will be difficult for a UI to convey the security properties of messages when you are interacting with users whose email clients don't support the recommended extensions, but there is always the risk that a recipient will copy-paste the plaintext of your securely sent message into an unsecured channel.
That analogy makes no sense.
Email is centralized because every time I send an email, I'm doing a DNS lookup.
By contrast, if I use a true P2P solution, I never need to do a DNS lookup. My chats in Signal can't be disrupted by a change in MX records.
> In any case, it would be possible to further enhance email using something like SMTorP so that .onion addresses are used instead.
Yes, but then why are you using email at all? The whole point of email has been that it uses the domain registry as a routing mechanism.
It's like telling people that the WWW is decentralized as long as you use .onion addresses. That's not true because as soon as you get off of public domains, you're not on the WWW anymore.
> The same is true of any system which is proposed as an alternative to email.
I don't think you understand this topic.
There are protocols with encryption schemes built into them. Email is not one of those. From the article I linked:
> "A number of standards exist for end-to-end email encryption, but so far, none have reached critical mass with vendors. Take Symantec. It supports both the S/MIME and PGP/MIME encryption, says Symantec's Kriese. That doesn't mean that the system easily interoperates with those of other vendors."
That is in contrast to Signal Protocol, where all clients' E2EE are compatible with each other as long as they're using the same protocol.
I don't disagree with your general premise but Signal is not decentralised at all, and I'm pretty sure they don't hardcode the Signal API server IPs into their binaries so you still depend on DNS (plus their centralised servers).
And every time the Signal app connects to its centralized servers, you're doing a DNS lookup too.
> By contrast, if I use a true P2P solution, I never need to do a DNS lookup. My chats in Signal can't be disrupted by a change in MX records.
But Signal isn't a true P2P solution. As your linked description of the Signal Protocol states:
"It does not provide anonymity preservation and requires servers for the relaying of messages and storing of public key material."
> It's like telling people that the WWW is decentralized as long as you use .onion addresses. That's not true because as soon as you get off of public domains, you're not on the WWW anymore.
If you're using HTTP and HTML and hyperlinks and URIs, then you are using the WWW. I suppose you could say that .onion addresses are the Dark Web, but saying they are not part of the web is pointless gatekeeping, like saying that HTTPS sites aren't part of the web because some web clients don't support TLS.
> I don't think you understand this topic.
That makes two of us then.
> There are protocols with encryption schemes built into them. Email is not one of those.
Again, this is an unhelpful observation. HTTP is a protocol that doesn't have encryption schemes built into it, but we didn't decide to throw it away in order to make the web secure. Similarly we don't need to throw away all existing email protocols and clients in order to have secure messaging.
> That is in contrast to Signal Protocol, where all clients' E2EE are compatible with each other as long as they're using the same protocol.
No, email is exactly the same as the Signal Protocol in that regard, since all email clients' E2EE are compatible with each other as long as they're using the same (encryption) protocol. The fact that an SMTP server doesn't reject an email that isn't PGP encrypted is a feature, not a bug.
On the other hand, TLS by default would be nice
For example, suppose alice@example wants to send an encrypted message to bob@server. Alice's client could wrap the message to Bob as an encrypted payload to a message addressed to switchboard@server, so that her provider doesn't learn Bob's address, and her provider could replace her metadata with switchboard@example before sending it to Bob's, so that it doesn't learn Alice's address.
eg: How do you start a new chat – the primary function of this app? It's hidden in the "..." menu that looks like it contains the settings for the existing example chat.
What has bothered potential adoptees is the idea it needs their email account credentials. People who don't think it is super cool already don't seem willing to adopt it. It would be nice if that changed.
Need to tie up with an email provider and give people an email address on signup. Also needs intelligent grouping of said email with someone's gmail on both the invite/invitee side.
Also, there's another app being worked on called Stamp is a similar messaging system as well, but uses an HTTP based transport instead of SMTP.
The things that set Stamp apart is that is has:
* Spam mitigation in the base layer so relay operators don't need to deal with it
* An indirect address lookup system so you don't get tied to one Stamp provider.
* No attachment to PII to start accounts. (No phone number or email required)
Check out the whitepaper, it's not very long:
Approximately everyone on the internet has an email address.
And it would be good to include such information in the site, because crypto has already got a scammy smell, in general.
Will this always be the case?
And if I'm only talking to my friends via IM, why would I need spam protection? Or in other words , could I just use a free server?
Because there's a huge difference between free and paid.
It's a nice idea, but I likely will not continue using it or try to sell anyone I know on using it because it doesn't let me share conversations between my different devices (like my smartphone and my laptop). If someone replies to a chat I send from my phone, I want to see the reply (and the whole thread, really) on every device I have Delta Chat installed on.
So, matrix it is, I guess.
Yes, if receiver uses IMAP if I understand this correctly.
Edit: End-to-end encryption or not is maybe unrelated to IMAP use. E2E Encryption does not work with some email providers though.
> If you want to rather avoid end-to-end-encrypted e-mails by default, use the corresponding Autocrypt setting in “Settings” or “Advanced settings”.
Here is a list of tested providers:
Also, end-to-end-encryption is not related directly to IMAP.
The issue with Hey/Protonmail/Tutanota is that they do not offer IMAP- or other standard-protocol-support - so you can just not log in with Delta Chat (nor with any other e-mail-client) to your Hey/Protonmail/Tutanota account.
If you log in to deltachat say with Posteo, you can write to other Hey/Protonmail/Tutanota accounts - but as the recipient cannot use Delta or other Autocrypt capable clients (Enigmail, K9), things cannot be encrypted. If Hey/Protonmail/Tutanota would support Autocrypt in their webclients, of course, this can change.
The IM landscape is indeed in a bad shape currently. I hope Matrix will take the lead eventually. But not even Signal will help in that regard https://community.signalusers.org/t/make-signal-use-matrix-p...
I don't see anywhere in DeltaChat's spec  anywhere it breaks compatibility with normal IMAP.
So long as your email client can use autocrypt standard (plugins exist for Outlook, Thunderbird, etc.), then you can make use of DeltaChat emails as normal emails.
I think the useability problem is just that webmail as a whole has generally been stripped of features. If Gmail wasn't as constrained a client, you'd be able to do everything without caring if you had a "DeltaChat" client. It isn't an email-or-DeltaChat question. Both interact fine.
But the clients people are currently using go out of their way to make it harder/impossible to do simple things.
Say person A sends an email to B with CC set to C.
C then needs to reply to this email, but send the reply to D, with A as BCC and E as CC. From what I remember, such fine-grained mail sending configuration is not possible with DeltaChat because it does not fit common group chat mechanics.
> I think the useability problem is just that webmail as a whole has generally been stripped of features.
Yes, I agree
It's a shame this wasn't more visible last week when there was a big uptake of signal (or was it?).
I’m assuming it piggybacks on your normal email address as opposed to making you create a dedicated one for chat.
If you set email interaction to "all" then you see regular email appearing as a "contact request" if you haven't already accepted the sender. In current development repos there is already support for mailing lists, and for html-mail. With this and a few other improvements, delta chat can be used as an e-mail client in more situations.
It might be useful to actually define a new email header field (Or define a new value to put into an existing field), thereby making this an open protocol.
It's how the whole messaging drama. Should be resolved and it's using decentralized infrastructure that is already there and reliable.
>Delta Chat doesn’t have their own servers but uses the most massive and diverse open messaging system ever: the existing e-mail server network.
Doesn't that mean Google effectively owns it, with central control, tracking and other "benefits"?
(For those who don't get the joke, see Front: