4 ms·

took me way too long to find out that the T in TMTP stood for Trusted. I was looking for protocol descriptions in how this could work. Author said people would

took me way too long to find out that the T in TMTP stood for Trusted. I was looking for protocol descriptions in how this could work. Author said people would be more impressed by code - but I think a protocol spec along with a reference implementation would be useful. So... what in this proposal isn't fulfilled by a private walled message platform such as Whatsapp, or Signal, or Facebook Messenger? Nothing here needs this to be 'email'. And if you're into adding trusted layers with revocation to email, well we have DKIM, client certs, encryption. You can do the 'trusted' enforceability at the application level over the untrusted SMTP network level. All in, probably DOA as an idea.

nobody9999 6y ago
>I was looking for protocol descriptions in how this could work. Author said people would be more impressed by code - but I think a protocol spec along with a reference implementation would be useful. I went and looked for a protocol spec as well. When I didn't see anything concrete on the site in the submission title, I poked around the comments a bit more and found a link to the Github issue[0] requesting detail with respect to the architecture of the TMTP protocol. I further poked around in the appropriate places[1] but found nothing remotely related. The protocol spec[2], while useful in defining the control mechanisms and message formats is vague or silent when it comes to a variety (too many to list completely here) of functional, operational and implementation issues. A comparison of TMTP's spec with SMTP[3] ("the protocol at the root of all these problems"[2] with messaging), is quite illuminating. While SMTP by itself lacks a variety of features, it provides a robust, interoperable architecture that's broadly supported and has been augmented repeatedly by other protocols (e.g., MIME, DMARC/DKIM, SMTP-AUTH, LDAP, etc.) to provide such features. It's not clear to me that mnm/TMTP has been fleshed out enough to provide a real alternative to SMTP+extensions. Rather, it appears to be another (there are many) client/server messaging application that's not interoperable. Should these issues be addressed, discussed and refined in the appropriate forums[4], It's possible that TMTP could turn out to be a viable replacement for SMTP. I applaud the authors' work and hope they have much success with their entry in the messaging app market. [0] https://github.com/networkimprov/mnm/issues/5 https://github.com/networkimprov/mnm/issues/5 [1] https://www.ietf.org https://www.ietf.org [2] https://mnmnotmail.org/rationale.html https://mnmnotmail.org/rationale.html [3] https://tools.ietf.org/rfc/rfc5321.txt https://tools.ietf.org/rfc/rfc5321.txt [4] https://www.ietf.org/how/wgs/ https://www.ietf.org/how/wgs/ Edit: Fixed links.
- networkimprov 6y ago
  The protocol draft: https://github.com/networkimprov/mnm/blob/master/Protocol.md https://github.com/networkimprov/mnm/blob/master/Protocol.md And yes, TMTP will see a lot more revision, and real-world use, before it's proposed to any standards body. (I'm the author.)
  - nobody9999 6y ago
    Thanks for the response. Yes. That was the document I was talking about, but I linked the wrong page. My apologies for any confusion.
als0 6y ago
Just been thinking that it's bad to use 'trusted' in an acronym. Not only is it subjective but it will also not stand well over time. Just like how NG is avoided.
networkimprov 6y ago
If widely adopted, most TMTP clients would have concurrent logins to many servers at different sites. Your traffic isn't routed via a middleman like Facebook which everyone needs to join, and which scans your content for advertising purposes. I've implemented both client and server, so there's the basis for a "reference implementation". More here: https://news.ycombinator.com/item?id=25804869#25807379 https://news.ycombinator.com/item?id=25804869#25807379 (I'm the author.)

nobody9999 6y ago

>I was looking for protocol descriptions in how this could work. Author said people would be more impressed by code - but I think a protocol spec along with a reference implementation would be useful. I went and looked for a protocol spec as well. When I didn't see anything concrete on the site in the submission title, I poked around the comments a bit more and found a link to the Github issue[0] requesting detail with respect to the architecture of the TMTP protocol. I further poked around in the appropriate places[1] but found nothing remotely related. The protocol spec[2], while useful in defining the control mechanisms and message formats is vague or silent when it comes to a variety (too many to list completely here) of functional, operational and implementation issues. A comparison of TMTP's spec with SMTP[3] ("the protocol at the root of all these problems"[2] with messaging), is quite illuminating. While SMTP by itself lacks a variety of features, it provides a robust, interoperable architecture that's broadly supported and has been augmented repeatedly by other protocols (e.g., MIME, DMARC/DKIM, SMTP-AUTH, LDAP, etc.) to provide such features. It's not clear to me that mnm/TMTP has been fleshed out enough to provide a real alternative to SMTP+extensions. Rather, it appears to be another (there are many) client/server messaging application that's not interoperable. Should these issues be addressed, discussed and refined in the appropriate forums[4], It's possible that TMTP could turn out to be a viable replacement for SMTP. I applaud the authors' work and hope they have much success with their entry in the messaging app market. [0] https://github.com/networkimprov/mnm/issues/5 https://github.com/networkimprov/mnm/issues/5 [1] https://www.ietf.org https://www.ietf.org [2] https://mnmnotmail.org/rationale.html https://mnmnotmail.org/rationale.html [3] https://tools.ietf.org/rfc/rfc5321.txt https://tools.ietf.org/rfc/rfc5321.txt [4] https://www.ietf.org/how/wgs/ https://www.ietf.org/how/wgs/ Edit: Fixed links.

networkimprov 6y ago
The protocol draft: https://github.com/networkimprov/mnm/blob/master/Protocol.md https://github.com/networkimprov/mnm/blob/master/Protocol.md And yes, TMTP will see a lot more revision, and real-world use, before it's proposed to any standards body. (I'm the author.)
- nobody9999 6y ago
  Thanks for the response. Yes. That was the document I was talking about, but I linked the wrong page. My apologies for any confusion.

als0 6y ago

Just been thinking that it's bad to use 'trusted' in an acronym. Not only is it subjective but it will also not stand well over time. Just like how NG is avoided.

networkimprov 6y ago

If widely adopted, most TMTP clients would have concurrent logins to many servers at different sites. Your traffic isn't routed via a middleman like Facebook which everyone needs to join, and which scans your content for advertising purposes. I've implemented both client and server, so there's the basis for a "reference implementation". More here: https://news.ycombinator.com/item?id=25804869#25807379 https://news.ycombinator.com/item?id=25804869#25807379 (I'm the author.)