> 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.
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.
1. https://en.wikipedia.org/wiki/Signal_Protocol