This is the twenty-third post in the Fastmail Advent 2024 series. The previous post was Dec 22: Why we use our own hardware at Fastmail. Check back tomorrow for the final post.
Exactly 10 years ago, we announced JMAP on our blog, along with a video by baby-faced Bron and Neil!
JMAP: A better way to email. We knew it would be a long road, but we’re really glad we did it and created an open standard rather than staying with our own custom protocol.
Some moments along the way
We started by workshopping the idea around the industry. I did a lightning talk at OSCON in 2014, our first attempt to find developers who could give us feedback on our design. By far the best find was Ricardo Signes, Pobox developer, who I met at a bar on the last day! This led to us acquiring the product and (our main goal) acqui-hiring Rik, who is now one of the company owners, as well as a JMAP enthusiast!
Neil and I attended Inbox Love in the Bay Area in 2014 as well. This gave us a chance to meet some of our technical peers in the big companies, relationships which we have continued to foster over the years. This hasn’t led to everyone dropping everything and implementing our protocols, but it has led to some collaborative design and ongoing conversations, and I believe its has prevented a proliferation of other protocols since people point to JMAP instead of inventing a new thing themselves. We also were told “go to the IETF”, but the IETF seemed big and scary and we didn’t know how, so that took a while.
Instead, we joined CalConnect and started working on Calendar formats and standards, while promoting JMAP more generally. Eventually we made more contacts in the IETF, and finally in 2017 went to our first IETF meeting in Chicago. At this point, the JMAP working group was born.
In the crucible of the IETF, we made major changes. The authentication was removed. Method names were split into Object/action and a ton of smaller changes were made. The Core and Mail JMAP specifications were published in 2019, and then we got to work on the rest of the stack.
JMAP Contacts was published just last week, and JMAP Calendars is very close to being published. I’m also keen to add Filenode support, but we want to get more experience with other filesystem providers before we standardize that (it’s currently based very closely on Fastmail’s own custom Node objects for our filestorage feature).
What’s next
We created JMAP because we could see that without it, the email world was going to become more insular, with the only modern standards for email access being proprietary. With Calendars and Contacts, we’re bringing the same easy-to-use JSON objects under a single protocol.
We started the Make Better Email conference last year, focused on improving the authentication workflow and also promoting JMAP usage. It’s a very small, invite-only conference where we do deep technical design work on improving interoperability and discoverability between clients and services. It was in Philadelphia last year, London this year, and we expect to be in Philadelphia again next year — likely in mid November after IETF 124 so we don’t cross over Halloween. If you think you’d be a useful addition to the meeting, pop us an email via the link at the bottom of the site.
Some work products of the previous conferences have been:
Over the past year some of us have also been working in the server-to-server space with an idea that may wind up replacing or enhancing DKIM.
And finally, next year we will be investing a lot more effort into making the Cyrus IMAP server not just a reference implementation for JMAP, but much easier to both develop and run.
In 10 years time, I hope to post about how Cyrus and JMAP have taken over the world, but I’ll also happily settle for them having both improved Fastmail’s product immeasurably, having plenty of happy customers, and continuing to help make email better for everybody through our work.
