We need better client support for JMAP. Apple Mail, Thunderbird, Outlook (as if), and so on. I'm surprised some of the smaller ones like Canary or Spark don't implement it as a product differentiator.
JMAP for Calendars, Contacts and Files Now in Stalwart
21–30 of 204 posts
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#22Anyone got a link to a better sales job on JMAP & friends? It sounds awesome but the way it is intro'd here: Over the past few years, the IETF has been redefining how email, calendars, and contacts are synchronized and shared. Building upon the success of JMAP for Mail, several new protocol extensions have been introduced: JMAP for Calendars - A modern replacement for CalDAV and CalDAV Scheduling. JMAP for Contacts –…
You may only just have heard of them, but the WG goes back to 2017. https://datatracker.ietf.org/wg/jmap/history/ Bron is the principal of fastmail, who now own pobox. This is a serious activity.
Counterpoint: I Google'd "jmap gmail" and a top result is a comment from HN in 2019 saying Gmail will never implement JMAP (it has not)
That's a really cruel response, because this is important work. I don't want my kids beholden to bigco.
I think it's real & important.
I also wanna make sure people like me, who have to keep tabs on the intersection of "how can I help liberate from BigCo" and "how can I make a livable wage doing so"
It is, quite literally, real, but also something you shouldn't waste time on if you're already busy. (c.f. https://jmap.io/software.html)
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#23Anyone got a link to a better sales job on JMAP & friends? It sounds awesome but the way it is intro'd here: Over the past few years, the IETF has been redefining how email, calendars, and contacts are synchronized and shared. Building upon the success of JMAP for Mail, several new protocol extensions have been introduced: JMAP for Calendars - A modern replacement for CalDAV and CalDAV Scheduling. JMAP for Contacts –…
Agreed, also not clear what this or why it matters. This is a new self-hostable email server basically?
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#24I wish there was an easy auto-update process for Stalwart. is anyone hosting an apt repo for it?
edit: we use it on very resource constrained environments, the container version is too much overhead.
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#25I can understand why JMAP instead of IMAP given the latter's antiquated design. I don't see the advantage to clients in replacing WebDAV though, and the others are a bit iffy too. They'll need to make a way better sales pitch than 'JSON vs XML' (serialization ain't tough, XML is supported everywhere).
I guess contacts/calendar follows JMAP naturally when the clients already implement it, but that only applies in the 'already wrote a JMAP email client' case. Virtually any other case would rather stay with widely supported protocols?
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#26Anyone got a link to a better sales job on JMAP & friends? It sounds awesome but the way it is intro'd here: Over the past few years, the IETF has been redefining how email, calendars, and contacts are synchronized and shared. Building upon the success of JMAP for Mail, several new protocol extensions have been introduced: JMAP for Calendars - A modern replacement for CalDAV and CalDAV Scheduling. JMAP for Contacts –…
The big pitch for JMAP is for a modern web-tech-only approach to email/calendar/"groupware" servers. One reason to do that would be to make it easier to also build email/calendar/"groupware" clients entirely out of modern web-tech. Today most "web email clients" are bespoke to specific stacks/email servers. A dream of JMAP is that with the right CORS policy a single web client could interact with multiple JMAP servers, using only fetch/XHR.
The modernization efforts of JMAP are interesting, too. Most of the old protocols are a mess of bespoke plaintext formats full of quirks evolved over decades in a giant mess of different software. Even the stuff that was already web tech like WebDAV and its extensions CalDAV and CardDAV were full of quirks, violated some REST "rules", and originally intended for a different purpose (file shares/FTP replacement). JMAP is much closer to "plain REST" than WebDAV's complex HTTP protocol extensions/changes.
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#27We need better client support for JMAP. Apple Mail, Thunderbird, Outlook (as if), and so on. I'm surprised some of the smaller ones like Canary or Spark don't implement it as a product differentiator.
Serious question: what’s the differentiator if major email providers don’t support it?
(This should not be interpreted as a defense of IMAP.)
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#28Running Stalwart in production for ~20 heavily used accounts for some company and no problems so far! The simplicity for such a complex stack and flexibility of deployments is off the charts!
I second that; only running it for personal use on a few domains, but handles all the complexity _extremely_ easily.
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#29Anyone got a link to a better sales job on JMAP & friends? It sounds awesome but the way it is intro'd here: Over the past few years, the IETF has been redefining how email, calendars, and contacts are synchronized and shared. Building upon the success of JMAP for Mail, several new protocol extensions have been introduced: JMAP for Calendars - A modern replacement for CalDAV and CalDAV Scheduling. JMAP for Contacts –…
If you look it up, you'll see that JMAP is 6 years old now. It's a protocol for doing email (and now other things) over HTTP, without many of the legacy issues from IMAP and SMTP.
https://en.wikipedia.org/wiki/JSON_Meta_Application_Protocol / https://jmap.io/index.html
Re: JMAP for Calendars, Contacts and Files Now in Stalwart
#30While JMAP seems to scratch every itch of a sucker for proper web API design, I’m wondering if the design space for new protocols should really be constrained to layers on top of HTTP. Is there really any new-ish binary protocol these days? Stuff like file sharing or groupware, mail, calendars, and so on—these things could be a lot more efficient and don’t really need the overhead of JSON as the message interchange f…
I wonder if you could transparently upgrade to CBOR over HTTP/2.