[networkimprov]

(Author here.) Development has been paused for ~1y as I've been at work creating a vehicle to take this forward.

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

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

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

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.

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

[karmakaze]

> TMTP messages pass through a single service which you explicitly joined.

This seems like a product rather than an internet draft protocol.

[networkimprov]

A TMTP client can subscribe to any number of TMTP services at different sites.

[GekkePrutser]

Really you shouldn't introduce a new service in 2022 without E2EE by default IMO. Not if you want it to be useful going forward :)

[nominusllc]

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

I don't think they meant this with sincerity. It's unpolished, which is accurate, but there's promise there, and I think their frustration was the last 20%, which is often overlooked- the cohesion of marketing babble and featureset.

[eis]

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.

[networkimprov]

Wow, have to ask whether you're interested enough to contribute? :)

    > You can't use a volatile cache ...
    > all this work to juggle JSON in flat files

I really don't think I've misused the cache! I didn't use SQLite because ordinary admins need to be able to inspect and occasionally fix the database. That decision can be revisited down the line.

    > Companies don't want to host heir own email servers

TMTP is more like HTTP than SMTP. There must be many ways to host a service, just like a website. Any admin must be able to bring up a TMTP server. (It's nothing like getting a new MTA host to work with the SMTP network!)

I discuss the E2EE issue on the mnm website FAQ. Only certain kinds of TMTP sites will want it to be the default. If a consumer tech brand offers an online TMTP client, it would present a proprietary API to the browser, as Gmail does; TMTP can't protect those messages.

    > synchronization between multiple client devices?
    > permissions in groups?
    > identity verifications?
    > mobile clients which don't want to open dozens persistent connections?
    > the demo doesn't actually use the protocol?

Client sync is implemented already \o/ - that's the replicas feature. It already has simple, user-defined groups. Admin-defined groups is on the roadmap; need user input to chart a course here. I've implemented OpenID Connect auth for new account registration. It could also be required per login, if there's demand. JMAP offers a model for how to do non-persistent connections on mobile devices. The demo is just the browser-based UI to the client, reconfigured to use canned data. (The client is a localhost web app.)

And, hey, can't a protocol can be a work in progress? I'm only willing to spec what I am ready to implement!

[georgia_peach]

Wrong place to share. The harmless people here will nitpick you to death as the adult version of sucking-up to teacher & showing how smart they are. The dangerous ones will silently steal the better parts of your idea & run with them, but with better funding & connections.