7 ms·

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 m

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.

smt88 6y ago
Email is a wheel that needs reinventing. It's fundamentally difficult/impossible to secure.
- ognarb 6y ago
  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.
  - Jarwain 6y ago
    Well there's the Matrix Email Bridge: https://matrix.org/docs/projects/bridge/matrix-email-bridge https://matrix.org/docs/projects/bridge/matrix-email-bridge
- Triv888 6y ago
  The data of emails is very easy to secure, but the metadata is another story... for example, your email could consist of a single gpg file.
- buster 6y ago
  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.
  - ajvs 6y ago
    It's really hard to do E2EE in a user-friendly way with email for starters.
    - buster 6y ago
      That's what the app does and simplifies.
  - smt88 6y ago
    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. https://www.csoonline.com/article/3224410/is-universal-end-to-end-encrypted-email-possible-or-even-desirable.html https://www.csoonline.com/article/3224410/is-universal-end-t...
    - dane-pgp 6y ago
      > 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. [0] https://github.com/mailpile/Mailpile/wiki/SMTorP https://github.com/mailpile/Mailpile/wiki/SMTorP
- gsich 6y ago
  See Deltachat.
- hkt 6y ago
  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? On the other hand, TLS by default would be nice
  - spicybright 6y ago
    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.
    - dane-pgp 6y ago
      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.
arendtio 6y ago
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 ;-)
- comboy 6y ago
  https://github.com/sessionbird/xmpp-smtp-gw https://github.com/sessionbird/xmpp-smtp-gw https://github.com/Puppet-Finland/milter-xmpp/ https://github.com/Puppet-Finland/milter-xmpp/ 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.
- gsich 6y ago
  Bridges require non-stop maintenance, because if users "feel" that their messages don't cross the bridge, they won't use it.
- vascocosta 6y ago
  Yes, that's probably the reason, especially the fact that the person on the other side doesn't even need to be aware of Delta Chat. 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.
deleted 6y ago
[deleted]

smt88 6y ago

Email is a wheel that needs reinventing. It's fundamentally difficult/impossible to secure.

ognarb 6y ago
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.
- Jarwain 6y ago
  Well there's the Matrix Email Bridge: https://matrix.org/docs/projects/bridge/matrix-email-bridge https://matrix.org/docs/projects/bridge/matrix-email-bridge
Triv888 6y ago
The data of emails is very easy to secure, but the metadata is another story... for example, your email could consist of a single gpg file.
buster 6y ago
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.
- ajvs 6y ago
  It's really hard to do E2EE in a user-friendly way with email for starters.
  - buster 6y ago
    That's what the app does and simplifies.
- smt88 6y ago
  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. https://www.csoonline.com/article/3224410/is-universal-end-to-end-encrypted-email-possible-or-even-desirable.html https://www.csoonline.com/article/3224410/is-universal-end-t...
  - dane-pgp 6y ago
    > 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. [0] https://github.com/mailpile/Mailpile/wiki/SMTorP https://github.com/mailpile/Mailpile/wiki/SMTorP
gsich 6y ago
See Deltachat.
hkt 6y ago
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? On the other hand, TLS by default would be nice
- spicybright 6y ago
  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.
  - dane-pgp 6y ago
    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.

arendtio 6y ago

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 ;-)

comboy 6y ago
https://github.com/sessionbird/xmpp-smtp-gw https://github.com/sessionbird/xmpp-smtp-gw https://github.com/Puppet-Finland/milter-xmpp/ https://github.com/Puppet-Finland/milter-xmpp/ 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.
gsich 6y ago
Bridges require non-stop maintenance, because if users "feel" that their messages don't cross the bridge, they won't use it.
vascocosta 6y ago
Yes, that's probably the reason, especially the fact that the person on the other side doesn't even need to be aware of Delta Chat. 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.

deleted 6y ago

[deleted]