This highlights the fact that there are too many protocols that are essentially reinventing the wheel. The problem isn't necessarily too many clients, but too many transport agents.
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.
While I agree, I think using e-mail as the base is an attempt to compensate for the network effect. While XMPP is clearly superior as a chat protocol, it lacks a broad user-base.
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.
Maybe we need email over the matrix protocol. Decentralized and using an already existing modern open protocol. The problem is that email has too much inertia.
Why do you think that? What would yet another protocol nobody uses bring to the table, smtp and imap don't? It's reliable, stable, decentralized and can be used securely.
Email is not decentralized. It relies on the central authority of domain registries. You theoretically can send emails in a more P2P way by using IP addresses, but then you lose the "reliable" and "stable" parts for many users.
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.
> Email is not decentralized. It relies on the central authority of domain registries.
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.[0]
> 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.
> By that definition, almost every chat app is centralized, especially if you include the step of downloading it over HTTPS.
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[1], where all clients' E2EE are compatible with each other as long as they're using the same protocol.
> 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.
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).
> Email is centralized because every time I send an email, I'm doing a DNS lookup.
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[1], 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.
Metadata being available to the server isn't ideal, but a hub and spoke architecture where the hub has no knowledge of which spokes are talking is, if not impossible, then at least very hard, surely?
I feel like the first step is consistent encryption, then figuring out hiding meta data. Proxys that strip meta + delay emails to fuzz that might be a solution.
Agreed. In fact, if consistent E2E encryption could be assumed, then the proxies could be implemented as simply a dedicated address on each server.
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.
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.