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!
> Wow, have to ask whether you're interested enough to contribute? :)
Sorry but I don't have a lot of spare time. I think you have some ambition with this project and it'll be a good amount of work.
> I really don't think I've misused the cache!
Hm what about the scenario I outlined? I might be missing something but I don't see how a cache can be used to check if something exists in persistent data.
> I didn't use SQLite because ordinary admins need to be able to inspect and occasionally fix the database.
I see your point though I think any sysadmin nowerdays needs to be able to do basic tasks for databases and especially something like SQLite.
> 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!)
Maybe in terms of simplicity of setting up a server yea but other than that this protocol and HTTP have not much in common.
> And, hey, can't a protocol can be a work in progress? I'm only willing to spec what I am ready to implement!
Of course. Well, you're trying to build something so more power to you I guess. Just trying to give some constructive criticism even if it initially might have been a bit harsh. Good luck with it anyways!
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.
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!