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.
And it's about time somebody came along and built something sane for this.
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.
JMAP defines the protocol first. Then, multiple people can take a stab at the most sane implementation. I like this approach quite a bit.
Clients leave IMAP ports open indefinately; IMAP IDLE provides push e-mail over this mechanism.
Reading about JMAP, this just seems like adding unnecessary web overhead and complexity to an already complex problem space.
Besides, JMAP could be consumed directly by web apps.
I don't understand why i should implement Fastmails web API, when there are several major protocols that are supported by a huge ecosystem already: IMAP, CalDAV, CardDAV.
Why building on mature concepts that have proven themselves in practice over several decades? It's much more in line with the current web culture if smart rockstar developers half-assedly cobble together a RESTful shit fest.
Changes, or online access, could be done using any standard remote file access method, such as sftp.
Are there downsides to this approach?
You need to be able to push email status changes out to connected devices, I don't want an alert for an email on phone if I've already read it on my laptop.
You need decisions around how attachments are stored. Most of the time you'll want to store the attachments separately from the text content of the email so clients don't have to download the attachments to access the text, so you'll need to decide on how this location would be communicated to a client.
Plain files are rather bad for multi-user access, if you have multiple users/devices all accessing the same email they're going to need some protocol for synchronization so you don't get data corruption or lost changes.
This. This sucks so much. Even gmail can't automatically dismiss a notification when I read a mail on the desktop!
Git's garbage collection would eventually remove references to orphaned objects and the transfer protocols would only push (or fetch) objects the other repository doesn't have.
I don't know how it would scale in terms of performance though.
IMAP/JMAP will work fine in those conditions, as a client can simply fetch the list of folders and a few email headers, and then lazily fetch email bodies on demand. Updating the read status is pretty cheap and does not require a full sync between the device and server, and so on.
Also, some IMAP servers store message flags in the filename (when using Maildir). This means that a message that goes from unread to read, it would appear to rsync that one file was deleted and another created (as the filename on disk has changed); the "newly created" file (which could be many MBs in size, depending on its contents/attachments) would then have to be completely synchronized again.
I didn't realize just how inefficient it was until a few days ago when I read an article  comparing rsync against ZFS replication (even if you're not familiar with ZFS, you'll understand).
If you run it the normal way this is (sadly) true.
However you can use the `--fuzzy` flag to make the behaviour a little more clever in handling this specific case.
The fact that it also handles calendars and contacts is icing on the cake.
Piggybacking it over HTTP also looks a bit strange, but probably helps corporate firewall penetration.
Does anyone know of such a bridge? I would love to run one for myself.