Seems like a poorly thought out protocol.<p><pre><code> 1. Inconsistences like the value for "op" being sometimes integer but then sometimes string. Why is this an integer anyways? We are already in inefficient JSON land and a lot of the rest is strings.
2. No mentioning of ordering or guarantees in the draft spec. Bad recommendation to use time for sequential message ids.
3. Says E2EE not in it right now but planned. Says E2EE not default because sites want to scan and archive messages but then the page says email is bad because it doesn't have E2EE and nodes can scan messages?
4. The usage of the word "node" is confusing and inconsistent. Sometimes it's described as a device, sometimes it's a password. "nodeid", "node", "newnode"...
5. Seems like one can spoof the alias for each message? What's the reason for this? The page specifically mentions phishing being an issue with email but wouldn't this help phishers? There is no way that I can see if a message came from the site itself or a random user on it.
</code></pre>
Then a quick look at the code. First noticed the unusual (for Go) coding convention like "tFoo" structs, "eErrFoo" errors. Calling a mutex "door", weird "//:" comments.
I haven't tested it but I'm fairly sure the convoluted way of storing user info in flat files has path traversal issues. Seems like there's a cache for alias -> uid but anyone can pick any alias so they would collide?<p>Just from a cursory glance. Also doesn't seem like it has moved much in a couple years.
I’m struggling to understand what this actually does. I poked around looking for information on the actual protocol, read through the site, and I don’t understand what this solves. The mechanics of the protocol aren’t very well defined, and the site says a lot of things without giving much information. TMTP isn’t an idea I would invest in and it’s nice that people are working on new protocols.
It seems to be conflating a communications protocol, an application level list management protocol, and parts of a message format.<p>It'd be far more likely to gain support if they unbundled this and made it work as an upgrade over e-mail, which would seem to make a lot of the spec redundant.
I don’t quite understand how this works. They say it’s a new protocol but it’s still using a browser which would imply it’s layered on top of UDP or TCP.<p>Building a new protocol today is kinda like inventing a new engine that doesn’t require gas, it’s gonna need a giant motivator to be adopted and trillions of dollars.<p>The days of grassroots bootstrapping are over, no one has any reason to adopt your thing because what we have now is Good Enough(tm). Your new thing needs to be revolutionary AND have government backing across multiple governments and administrations. There is no other way, consider the electric car vs hydrogen.
Not sure about the “features” at the end. Specifically Markdown support. This is a client-side issue. If MUAs parsed Markdown, then there is no reason that markdown couldn’t replace html in the relevant part of a MIME multipart message. The SMTP server only handles ASCII characters; it really doesn’t care how that is presented. It also afford the possibly of plaintext as a fall back. Arguably, you could have all three.
Interesting. The protocol TMT, seems to have the idea of users having multiple nodes (which are referred to in comments as devices). I suspect if I were to use this in a product, I'd use nodes for application instances instead, so if a user had multiple apps (i.e. consumer payment app and merchant dashboard app) on the same device I could keep them straight. Seems promising.
About time someone thought of replacing email protocols with something new but without adding the bloat that seems so inevitable today. I would also think of integrating functions to replace also NNTP (News, USENET), so that it would cover all needs between private one to one and public many to many communications.
Firstly, i love the recursive nature of the implementaion: "mnm is not mail"! Also, quite a fascinating approach; hoping it works out! Me being a fanboy of the matrix protocol, I've often wondered if there is a valid use-case for matrix to enable safe, secure communications between site user/customer, and site manager(s). Not just chat, but a sort of customer support mechanism, but also a safe, private mechanism for site managers and/or orgs to do reasanble outreach to user/customers. And, no, it need not be chatbots, though i suppose there would be a desire by some orgs for an implementation like that at the end of the day. My hope would be of course for a better chatbot than current standards. Obviously, there would need to be the delicate balance of ease of use, privacy for user/customer, ideally decentralization (for empowering liberty/freedoms), integrity of content conveyed (by way of non-tampering/security of content), etc.<p>In any case, good luck to the folks behind this effort; the more internet protocols (and not centralizied systems/orgs) that can help people, the better!