Cheers for the reply.

> The protocol specifics (e.g. identifiers & types) aren't polished, because I focused on features in working code. Thanks for the feedback!

Got it. IMHO it's better to start with a clean protocol spec before implementing features. At least for the very basic stuff. Of course for an MVP I wouldn't start with a spec but then again this seems past the MVP stage seeing as it started 2017 and wants to be a protocol and not just product.

> You can't have alias collisions; it checks whether the string you propose is acceptable & available :)

You can't use a volatile cache to check for collisions though. Unless I'm missing something and the "cache" is prefilled with all existing aliases somewhere and not volatile but then it wouldn't be a cache? Even if it did, it's asking for trouble.

> A sender's alias is (or will be) checked against their recorded aliases.

What about the following: 1. user A adds alias Foo 2. Server restarts 3. user B adds alias Foo 3. random other user sends message to alias Foo.

My point is a cache should just be used to speed up certain operations but has to be handled with care (cache invalidation etc). Better to skip this as it's just premature optimization and can just cause trouble.

In fact all this work to juggle JSON in flat files will cause more headache than it's worth. Just use something like SQLite and you'll save yourself a lot of time and issues. It'll make the implementation much easier especially to adapt. But it'll pay dividends for a long time (migrations etc). You'll run into filesystem limitations quite quickly anyways with these flat files.

> The reason why lack of E2EE in email is a serious problem is that email traverses at least two "federated" services, which are typically third parties with whom you have no intrinsic need for a relationship. A TMTP message passes through a single service which you explicitly joined.

But what prevents a "gmnm" here? Companies don't want to host heir own email servers and they might not want to run their own mnm servers. Nothing here guarantees to the user that he's directly communicating with the other party. And all data is also stored unencrypted.

As GekkePrutser mentioned in a sibling comment, it's 2022 and any new messaging protocol without E2EE will be dead on arrival. I'm maybe exagerating but it'll have a tough time. Especially if it justifies itself partially because email doesn't have E2EE.

> I don't see how your feedback justifies "poorly thought out"; it's merely an unpolished preview.

Maybe so. I just saw it mentioning problems with mature protocols like SMTP and Matrix and I agree with some of that criticism but the solutions are not in TMTP as far as I can see. What about synchronization between multiple client devices? What about permissions in groups? What about identity verifications? What about mobile clients which don't want to open dozens persistent connections? There is a long list of topics to cover when it comes to messaging protocols.

To create a new protocol isn't an easy task. A protocol should be precise and robust. To create a product? Much easier.

BTW no one forces people to federate when using Matrix. Or one could use something like the Signal protocol. Sure they are more complex than TMTP but they have to be because they solve a ton of non-trivial issues.

PS: Seems like the demo doesn't actually use the protocol at all? It looks like it just loads all static data from https://mnmnotmail.org/w/data-demo.js and basically is a static page.