
JMAP – an IMAP replacement - _e
http://jmap.io/
======
sciurus
Previous discussions of JMAP:

* [https://news.ycombinator.com/item?id=7141152](https://news.ycombinator.com/item?id=7141152)

* [https://news.ycombinator.com/item?id=8785894](https://news.ycombinator.com/item?id=8785894)

* [https://news.ycombinator.com/item?id=10781894](https://news.ycombinator.com/item?id=10781894)

* [https://news.ycombinator.com/item?id=14283659](https://news.ycombinator.com/item?id=14283659)

~~~
_e
Thank you! The first link goes to jmap.io and the other three go to blog posts
at fastmail.com that are 1+ years old.

I tried finding more info on JMAP from fastmail by searching for "jmap
site:blog.fastmail.com"
([https://www.google.com/?gws_rd=ssl#q=jmap+site:blog.fastmail...](https://www.google.com/?gws_rd=ssl#q=jmap+site:blog.fastmail.com))
but they haven't written anything relatively new unfortunately.

By searching for "jmap site:edu" in Google, I found:
[https://cyrusimap.org/](https://cyrusimap.org/)

Cyrus IMAP supports JMAP but I am unable to find any JMAP clients that are
being used in production.

~~~
fanf2
There is currently a standardisation effort at
[https://datatracker.ietf.org/wg/jmap/about/](https://datatracker.ietf.org/wg/jmap/about/)

------
pseudosavant
I can't believe I am saying this about something like an email protocol that
would normally be quite mundane, but there is some real elegance to the
simplicity of their approach by reusing what already exists (HTTP, JSON,
mobile OS push notifications). It all seems unbelievably rational, especially
for an email protocol standard.

~~~
dsr_
Then you probably would have liked Internet Mail 2000 (IM2000), a half-hearted
djb proposal: [https://cr.yp.to/im2000.html](https://cr.yp.to/im2000.html)

(I say half-hearted because when djb is enthused, the first people hear of it
is a complete first draft of a server and a client...)

~~~
fanf2
IM2000 would have been great for spam! The spammer can just blast out little
message availability notifications, containing links to their bulletproof
hosting or compromised servers.

------
sachinag
While we at Nylas did build our APIs to help with IMAP troubles, we also
handle Gmail (via IMAP) and Exchange as well. We'd be happy to add JMAP
support to our APIs if it takes off since we're committed to 100% coverage of
email mailbox accounts (including calendar via CalDav parsing).

(If the Fastmail people are reading this, feel free to contact me.)

~~~
xupybd
I used Nylas a little while ago, loved the N1 client. But had to stop due to
restrictions on emails being stored off site. Is there an option for people
wanting to use Nylas where they have restrictive security policies on where
email can be stored?

------
peterwwillis
tl;dr their new mail standard is a web app.

 _" Why use HTTPS/JSON? The short answer is it’s good enough, widely
understood and it’s by far the easiest thing for developers to adopt. There’s
support in basically all OSes and programming languages. It’s easy to read and
debug."_

Why not INI files, then, or a CSV, delivered over DNS? "Wide support and rapid
adoption" is great if you're trying to make money, but not necessarily a great
technical design framework.

The reason webapps work with HTTP/JSON is they had to. They were built on top
of old standards which had to be backwards compatible, and they had to work
around holes in the existing technology. So they took existing tech and
extended it, and made it simple enough for everyone to adopt it warts and all,
rather than improve it. We've been slowly patching its gross inefficiencies
ever since.

An IMAP replacement does not have to work over a web platform, so it does not
need this kind of unnecessary coupling of disparate, complicated standards to
make it more clunky. But they're doing it anyway. So, why build a complicated
new protocol on top of difficult, completely unrelated standards?

This new standard only exists as a vehicle for their own services and
products, because they need other people to adopt it for it to make sense as a
product they can make money on vs their competitors. They could have just
worked with the industry on the next generation of IMAP, but that wouldn't be
adopted "as quickly" to lock an industry into the model they are already
developing.

~~~
xupybd
HTTPS/JSON is common place, developers are familiar with debugging problems in
that stack. INI or CSV delivered over DNS would be esoteric an unknown to most
developers.

You might see it as more clunky but I think it's great that the transport and
security layer are bundled into something I already work with and know how to
debug. I don't think the extra overhead is a concern these days. Most servers
can handle that sort of load easily and most clients have not issue with
HTTPS/JSON.

------
dewey
> It’s based on years of experience and real-world experimentation at FastMail

Here's a nice blog post about that:
[https://blog.fastmail.com/2014/12/23/jmap-a-better-way-to-
em...](https://blog.fastmail.com/2014/12/23/jmap-a-better-way-to-email/)

------
grabcocque
I know that it's open source, and open, interoperable protocols are a good
thing.

But. I don't think IMAP is the real competition here. This is, for most
people, a solved problem, and a problem that's been solved by exchange and
gmail.

So for better or worse, showing you're better than IMAP doesn't cut it. You
have to show you're better than exchange.

One of the things I don't understand is why email protocols were allowed to
languish for so long, making proprietary groupware suites practically
mandatory for getting work done.

~~~
xupybd
I think you're last statement, in a way, answers your second to last.

> You have to show you're better than exchange.

> making proprietary groupware suites practically mandatory for getting work
> done.

It's not proprietary groupware is why it's better than exchange. I'd argue
that if you can get the same work done, you're winning.

~~~
horusthecat
> It's not proprietary groupware is why it's better

you must not work enterprise much

------
jiqiren
Seems like this is missing an RFC to make any real traction.

~~~
roblabla
You don't need RFC to get real traction, if clients/servers are written for
it. There is already an implementation in Cyrus SASL, and last I heard work
was ongoing for a dovecot impl.

I'm currently poking around the protocol, and thinking of implementing it into
K9-mail (A popular android email client, that happens to be open source). I'm
self-hosting my email already, and I'd really love to use this. It seems to
fit much nicer into the current ecosystem than IMAP.

~~~
kybernetikos
I'm using k9 with fastmail. I'd definitely use JMAP if it were an option.

------
nine_k
I hope someone will roll out a good (and preferably open) implementation for
Android and/or iOS. Email without a mobile client is a non-starter.

Open-source servers apparently exist (listed on the site).

