Dec 23: The JMAP momentum builds
Post categories
Chief Product Officer
This is the twenty-third post in the FastMail 2015 Advent Calendar. Stay tuned for our final post tomorrow.
In our advent blog series last year we announced JMAP, our effort to make a better standard for synchronising mail, calendars and contacts. Exactly one year on, we thought it would be good to give an update on our progress so far.
Replacing ageing technology standards takes time, even when there are huge advantages over the previous generation, but we were delighted to see significant advancements this year. We’ve been talking with mailbox providers big and small, as well as server and client developers, to raise awareness and get people onboard. And already, the momentum is building.
The next version of Roundcube (the world’s most popular open source webmail client) is being built on JMAP. Linagora are also using it for their next generation email platform, and are actively developing an open-source client library in ES6. Atmail similarly see JMAP as the future and are using it as a base for future products. Bigger platforms tend to take more time to adopt new things, but we have held productive talks on some of our trips over to California this year.
To spread the word, we’ve also been giving talks at various conferences over the last 12 months. Bron spoke at FOSDEM in Brussels back in January, and at the openSUSE conference and Kolab summit in the Hague in April, and then Bron and I both spoke at OSCON in Portland in July. (Incidentally, if you’re on the scheduling committee for a technology conference and you think a JMAP talk would be interesting, please do let us know!)
Meanwhile, we haven’t just been talking. We’ve also managed to find time to drive development forward too! In August we announced the release of a JMAP Proxy, which sits in front of existing IMAP/CardDAV/CalDAV servers and lets them speak JMAP. This is an important component in helping people to develop new clients and to experiment with the protocol. We even provide a free hosted version at https://proxy.jmap.io for people to play with – log in with a FastMail, iCloud, Gmail or other IMAP test account to start trying JMAP today!
To accompany the proxy, we open sourced our JavaScript JMAP client library, the basis for the next-generation FastMail interface. It supports lots of advanced features, such as asynchronous local changes, network failure tolerance, and multi-level undo/redo support. Of course we wanted to make it as easy as possible to try the client library and proxy in action today, so we built a simple – but in some ways quite sophisticated – webmail demo on top of the JS client library, and open sourced that as well.
Looking to the future, we’re excited about moving FastMail’s webmail onto a pure JMAP platform (at the moment we use something similar, but not quite the same). There are many features we want to do that will be easier and it will make a lot of our architecture cleaner and simpler (and even faster!). We’ve been hard at work building full JMAP support into Cyrus, the open-source mail server we use at FastMail, and it’s progressing well. This work is of course also fully open source and available for others to use, and we hope to persuade our friends at Dovecot to implement native support too. Once both the major open source mail servers have JMAP support, as systems upgrade they’ll be able to open up JMAP access to users with zero extra effort.
The spec has been fairly stable, but we need to finalise a version 1.0 and make sure we have a solid plan in place for versioning and future changes (inevitable, in the fast changing world of technology). If you would like to get involved in finalising the spec, or have questions or comments about implementing JMAP, then please join the JMAP mailing list.
If you run your own email service and want to get involved with the JMAP project, you can find full details of the specification, implementation advice and a link to the code on the JMAP website.
We strongly believe in the future of email, but the current protocols make it hard to develop on top of, especially without tying in to vendor-specific proprietary APIs. With JMAP, we hope that the future can be both better and open, and we look forward to seeing the innovation that will result from more widespread adoption.