This is great to hear. I'm glad the project is progressing.<p>For those not in the know, JMAP is a protocol for mail that, unlike IMAP, has threads and labels built-in at its core. In other words, Gmail without Gmail.<p>And it's about time somebody came along and built something sane for this.<p>There have been a lot of valiant attempts at this. Thunderbird has a few buggy extensions that attempt it. Notmuch is a very well written library and command line MUA with a very fast on-disk storage format (with ncurses, emacs, and vim interfaces, as well as neat FUSE file system toys), but it is not a protocol, and therefore does not scale well beyond the limited set of MUAs for it that mostly need a shell or a flimsy web app. Mailpile is an attempt at making a Web 2.0 style Gmail clone, but it's only an MUA and the on-disk format is flimsy at best.<p>JMAP defines the protocol first. Then, multiple people can take a stab at the most sane implementation. I like this approach quite a bit.
This might be a naive question, but I don't know any better: Why can't your mailbox be represented on a server as a directory, perhaps like Maildir format, and then synchronised to your device using a directory sync tool, such as rsync?<p>Changes, or online access, could be done using any standard remote file access method, such as sftp.<p>Are there downsides to this approach?
I'm pretty excited about JMAP. We've been planning an overhaul of Usermin, our web-based mail client, and now that we have a UI developer, we'll be embarking on more ambitious features, like threading, off-line abilities, etc. Having threading handled automatically is already reason enough to use this, as it's a much harder problem than it seems at first glance to solve in a consistent way across many clients and servers.<p>The fact that it also handles calendars and contacts is icing on the cake.
Reading about JMAP last year during their holiday series of blog posts persuaded me to jump on-board for their mail service and to support the evolution of JMAP. No regrets!
There seems to be a lot of interest in sync related protocols in this thread and dismissal of JMAP as a result. This is bad, because the current state if synchronization protocols still kinda sucks - full disclosure, I work on <a href="http://GitHub.com/amark/gun" rel="nofollow">http://GitHub.com/amark/gun</a> which is a JavaScript based syncing database. Getting synch right in p2p or federated systems (email) entails more detail than centralized ones. So any work on synchronization should be seen as favorable compared to how bad other protocols are for sync.
What somehow bothers me is that the new protocol is all-in-one. Instead of building on / integrating with CalDAV / CardDAV and being modular, they are rolling everything in the same protocol. This is possibly convenient for a protocol controlled by one commercial entity, but why not just use Outlook's then?<p>Piggybacking it over HTTP also looks a bit strange, but probably helps corporate firewall penetration.
My favorite part about this is that one can implement and start using it at their discretion (i.e. it doesn't require the other server to also speak JMAP). That way I can have a mobile app that speaks JMAP and an IMAP-to-JMAP bridge that syncs my Gmail to it.<p>Does anyone know of such a bridge? I would love to run one for myself.
Sadly, I don't see a lot of uptake on a new protocol unless Microsoft supports it in Outlook or someone develops a plug-in. Also, the mobile situation is going to be a tough haul.