networkimprov

What's your opinion of Etherpad? Does their roadmap overlap with your vision?

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!

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

FWIW, most of the roadmap for this project is not described on the website nor defined in the protocol.

This is a deep topic, and "messaging" is not the only goal, nor even the principal one :)

(Author here.) I imagine that existing web-based bulletin boards would simply copy messages to TMTP users if requested.

Conversely, TMTP groups/lists could be copied to a read-only website.

(Author here.) The message format definition is included in the protocol doc only as a convenience. Ultimately it would be two standards.

Trying to "upgrade" the email ecosystem is an impossible goal, and the requirements I'm working to can't be shoehorned into the email model.

(Author here.) Thanks for your interest & support!

Yes, the default concept for an Internet messaging service is "everyone can reach anyone". This isn't helpful for online services and businesses who need to reach their members/customers directly & securely, and with a rich content model (e.g. survey/form in message, and structured result in reply).

(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.

(Author here.) TMTP clients maintain concurrent (possibly intermittent) connections to any number of TMTP services, and each service gets its own inbox. So you don't need a separate app instance per service.

Inboxes for a set of related services could conceivably be merged, tho I haven't done any work on that yet.

(Author here.) The client UI is designed for desktop. A mobile frontend is in the works. Tentatively planning to use Ionic Framework with Vue.

Hi, author here, AMA!