Hacker News Reader

Comment by FiveNinjas | Hacker News Reader

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.

View on HN

>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

[1] https://www.ietf.org

[2] https://mnmnotmail.org/rationale.html

[3] https://tools.ietf.org/rfc/rfc5321.txt

[4] https://www.ietf.org/how/wgs/

Edit: Fixed links.

The protocol draft: 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.)

Thanks for the response.

Yes. That was the document I was talking about, but I linked the wrong page.

My apologies for any confusion.

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

(I'm the author.)

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.

Reply on news.ycombinator.com