Dec 23: Ten years of JMAP

This is the twenty-third post of the Fastmail Advent 2024 series. The previous post was December 22: Why we use our own Fastmail hardware. Come back tomorrow for the final post.
Exactly 10 years ago, we announced JMAP on our blogwith a video of Bron and Neil looking like kids!
JMAP: A better way to email. We know it’s a long road, but we’re glad we did it and created an open standard rather than sticking to our own standard protocol.
A few moments on the way
We started by workshopping the idea around the industry. I did a lightning talk at OSCON in 2014our first attempt at finding developers who could give us feedback on our design. So far the best search is Ricardo SignesPobox developer, whom I met in a bar the last day! This led to our acquisition of the product and (our main goal) hiring Rik, who is now one of the owners of the company, as well as a JMAP enthusiast!
Neil and I attended Inbox Love in the Bay Area in 2014 as well. This gave us the opportunity to meet some of our technical peers at major companies, relationships that we have continued to develop over the years. It didn’t lead to everyone dropping everything and implementing our protocols, but it did lead to some collaborative design and ongoing conversations, and I think it prevented the proliferation of other protocols because people focused on JMAP instead of inventing something new themselves. We were also told to “go to the IETF”, but the IETF seemed big and intimidating and we didn’t know how, so it took a while.
Instead we are together CalConnect and began working on Calendar formats and standards, while promoting JMAP more generally. Eventually we made several contacts with the IETF, and at the end of 2017 went to our first IETF meeting in Chicago. At this point, the JMAP working group was born.
At the crucible of the IETF, we are making big changes. Authentication is removed. Method names are divided by Object/action
and a ton of smaller changes have been made. the Core and Mail JMAP specifications were published in 2019, and then we worked on the rest of the stack.
JMAP Contacts published last week, and JMAP Calendars almost published. I also like to add Filenode support, but we want to get more experience with other filesystem providers before we standardize that (it’s currently based heavily on Fastmail’s own custom Node objects for our filestorage feature).
What’s next?
We created JMAP because we saw that without it, the email world would be more insular, with the only modern standards for email access being proprietary. With Calendars and Contacts, we bring the same easy-to-use JSON objects under one protocol.
We started the Create Better Emails conference last year, focused on improving the authentication workflow and also promoting the use of JMAP. This is a very small, invitation-only conference where we do deep technical design work on improving interoperability and discoverability between clients and services. Was in Philadelphia last year, London this year, and we hope to be in Philadelphia again next year – probably mid-November after that IETF 124 so we don’t cross Halloween. If you think you could be a useful addition to the meeting, pop us an email via the link at the bottom of the site.
Some of the work products of previous conferences are:
Over the past year some of us have also been working in the server-to-server space with an idea which may end up replacing or improving DKIM.
And finally, next year we will invest a lot of effort in making the Cyrus IMAP server is not only a reference implementation for JMAP, but easier to develop and run.
In 10 years time, I hope to be able to post how Cyrus and JMAP took over the world, but I am also happy to judge that both have improved the Fastmail product immeasurably, there are many happy customers, and continue to help make email better for everyone through our work.
https://www.fastmail.com/assets/images/hero-NpzR5QM2I5-1200.png
2024-12-23 02:26:00