Live data from Hacker News

Ten Years of JMAP

fastmail.com

11–20 of 83 posts

Re: Ten Years of JMAP

#11

JMAP is the best email protocol out there that nobody uses (besides Fastmail), sadly. It would be great that the two big email providers (Google and Microsoft) implemented and supported it. It would make so easier and reliable to have a single client that works really well across personal and business email accounts, for example.

I think the first "big tech" adopter would be Apple if anything. Their entire email stack is standard protocols.

But you have to ask on that scale, what would it bring them other than change if everything already works fine?

Re: Ten Years of JMAP

#12
post #7

Earlier quoted context omitted.

Sadly, Google and Microsoft are in the business of getting their users to use their own gmail and outlook clients. They don't want to be invisible IMAP/JMAP back-ends, they want to own your e-mail experience .

Besides, MS already have their own solution that goes way beyond just mail: Microsoft Graph

MSGraph is slower and not as convenient for email compared to JMAP. In addition to requiring more API calls for the same result, MSGraph starts throttling with HTTP 429 responses after several calls, making the initial synchronization much slower than JMAP or even IMAP.

Hopefully, next year there will be JMAP support for Contacts. As RFC drafts, there are already JMAP specifications for Files and Calendar...

Re: Ten Years of JMAP

#13
post #7

JMAP is the best email protocol out there that nobody uses (besides Fastmail), sadly. It would be great that the two big email providers (Google and Microsoft) implemented and supported it. It would make so easier and reliable to have a single client that works really well across personal and business email accounts, for example.

Sadly, Google and Microsoft are in the business of getting their users to use their own gmail and outlook clients. They don't want to be invisible IMAP/JMAP back-ends, they want to own your e-mail experience .

And they standardized MTA-STS to ensure that you must use web technologies if you want to use email.

Re: Ten Years of JMAP

#14
I get that this is a huge effort and that it takes a long time for protocol adoption (especially if the big companies aren’t behind it). I don’t know why Fastmail has developed mobile apps but no desktop applications so far. One justification could be higher usage on mobile, but it still leaves desktop users out (of JMAP).

Without more email clients supporting it, mail providers don’t have any incentive to support JMAP. Mozilla Thunderbird started looking at JMAP but hasn’t progressed on that all these years.

> In 10 years time, I hope to post about how Cyrus and JMAP have taken over the world

I believe the biggest hurdles are other email clients and providers not adopting it. The biggest threat is Microsoft, as usual, pushing its own protocols and client and using FUD to brainwash CIOs into believing that any protocol outside its own is a major security threat that just cannot be handled.

If either Apple or Google could be convinced to implement and support JMAP, this could take off a lot faster.

Re: Ten Years of JMAP

#15

Earlier quoted context omitted.

Besides, MS already have their own solution that goes way beyond just mail: Microsoft Graph

MSGraph is slower and not as convenient for email compared to JMAP. In addition to requiring more API calls for the same result, MSGraph starts throttling with HTTP 429 responses after several calls, making the initial synchronization much slower than JMAP or even IMAP. Hopefully, next year there will be JMAP support for Contacts. As RFC drafts, there are already JMAP specifications for Files and Calendar...

No doubt JMAP is superior for the problem it solves. I wonder if it will matter in the end though. I have the impression MS is positioning it self to be the only viable AI platform where mail and calendars are just a tiny part of that. So while not really competing in the same domain it may be that both IMAP and JMAP may feel as relevant to the world as IRC or XMPP in the not too distant future.

Re: Ten Years of JMAP

#16

JMAP is the best email protocol out there that nobody uses (besides Fastmail), sadly. It would be great that the two big email providers (Google and Microsoft) implemented and supported it. It would make so easier and reliable to have a single client that works really well across personal and business email accounts, for example.

I think the first "big tech" adopter would be Apple if anything. Their entire email stack is standard protocols. But you have to ask on that scale, what would it bring them other than change if everything already works fine?

> what would it bring them other than change if everything already works fine?

IMAP is absolutely terrible on unreliable connections. A connectionless protocol based on HTTP would do much better in those conditions.

Re: Ten Years of JMAP

#17
post #6

Earlier quoted context omitted.

I’m not exactly the biggest fan of JSON either but given the clusterfuck of established email technologies, moaning about JSON is a little hypocritical. https://en.m.wikipedia.org/wiki/The_pot_calling_the_kettle_b...

It's more: we have two clusterfucks now thus might as well use the one we know best. At least no one tried to use YAML on the wire, so far anyway.

And that one is JMAP. IMAP is such a huge clusterfuck it is almost impossible to beat it.

Re: Ten Years of JMAP

#18

JMAP is the best email protocol out there that nobody uses (besides Fastmail), sadly. It would be great that the two big email providers (Google and Microsoft) implemented and supported it. It would make so easier and reliable to have a single client that works really well across personal and business email accounts, for example.

I think the first "big tech" adopter would be Apple if anything. Their entire email stack is standard protocols. But you have to ask on that scale, what would it bring them other than change if everything already works fine?

JMAP uses fewer resources server-side, and with their scale, it will probably reduce operating costs. But it will depends on how much they will save compared with devel/migration costs.

Re: Ten Years of JMAP

#19

Earlier quoted context omitted.

I think the first "big tech" adopter would be Apple if anything. Their entire email stack is standard protocols. But you have to ask on that scale, what would it bring them other than change if everything already works fine?

> what would it bring them other than change if everything already works fine? IMAP is absolutely terrible on unreliable connections. A connectionless protocol based on HTTP would do much better in those conditions.

I'm not sure it does if I'm honest. The encapsulation via JSON is quite bad and transactional model of HTTP is non-existent. One of our key problems on our platform is deciding on how to handle failures like that in transactional systems. Email is to some degree transactional due to the distributed state. It's going to get ugly.

IMAP is ugly but that is all well understood.

Re: Ten Years of JMAP

#20

Earlier quoted context omitted.

MSGraph is slower and not as convenient for email compared to JMAP. In addition to requiring more API calls for the same result, MSGraph starts throttling with HTTP 429 responses after several calls, making the initial synchronization much slower than JMAP or even IMAP. Hopefully, next year there will be JMAP support for Contacts. As RFC drafts, there are already JMAP specifications for Files and Calendar...

No doubt JMAP is superior for the problem it solves. I wonder if it will matter in the end though. I have the impression MS is positioning it self to be the only viable AI platform where mail and calendars are just a tiny part of that. So while not really competing in the same domain it may be that both IMAP and JMAP may feel as relevant to the world as IRC or XMPP in the not too distant future.

I am more than happy to not use an "AI platform" for my e-mail and calendar!
Post reply on HN