Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ten Years of JMAP

fastmail.com

Post reply on HN
Print view View original

31–40 of 83 posts

Re: Ten Years of JMAP

#31

Post by brongondwana »

hyhconito wrote: post #19
noprocrasted wrote: post #16

Earlier quoted context omitted.

> 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.

The big benefit with JMAP is the state strings and /changes operation which allows even in the face of failures to recovery quite cleanly. It's really more a data synchronising protocol (RFC8620) with email support on top (RFC8621) and the new protocols coming in.

Re: Ten Years of JMAP

#32

Post by userbinator »

This? https://en.wikipedia.org/wiki/JSON_Meta_Application_Protocol

They cited IMAP's complexity, high resource use,

JMAP is implemented using JSON APIs over HTTP

They complain about complexity, then add another two layers of complexity in their own protocol?

I think POP3 is the simplest standard, and have also written a basic IMAP client. Parsing IMAP isn't as easy as a binary protocol, but it's definitely not at the level of HTTP JSON bloat that seems to have infected all "modern" protocol designers. I can use POP3 reasonably easily from a netcat (and have done so many times in the past), and IMAP is a little harder but doable. I don't expect that to be doable for JMAP which is text-based like the other HTTP JSON bloatocols, but unlike the earlier text-based standards like SMTP POP3 IMAP IRC MSNP etc., it seems to have all the disadvantages of a text-based protocol but none of the advantages.

Re: Ten Years of JMAP

#33

Post by Fnoord »

userbinator wrote: post #32

This? https://en.wikipedia.org/wiki/JSON_Meta_Application_Protocol They cited IMAP's complexity, high resource use, JMAP is implemented using JSON APIs over HTTP They complain about complexity, then add another two layers of complexity in their own protocol? I think POP3 is the simplest standard, and have also written a basic IMAP client. Parsing IMAP isn't as easy as a binary protocol, but it's definitely not at the…

POP3 has no locking. It won't work with multiple clients, and that is awful. But I agree with your assessment. We need good utilities which make JSON human-readable, and which turn human-readable into JSON. Might as well not use JSON, except for internal traffic.

Re: Ten Years of JMAP

#34

Post by brongondwana »

otabdeveloper4 wrote: post #23
jeltz wrote: post #17

Earlier quoted context omitted.

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

IMAP is simple and elegant and not a "clusterfuck" at all. (Source: implemented both serverside and clientside IMAP.) IMAP is basically a database query language and as such it works as it should.

IMAP is both excellent and, annoyingly inconsistent so it's much more of a pain to develop reliable parsers for. I'm pretty happy to use IMAP generally, but I'm also... MODSEQ is wrapped with a () in some places, not but STATUS HIGHESTMODSEQ:

  . SELECT INBOX.Archive
  * 1239 EXISTS
  * 0 RECENT
  * FLAGS (\Answered \Flagged \Draft \Deleted \Seen $X-ME-Annot-2 $HasAttachment $IsNotification $IsMailingList $NotJunk $CanUnsubscribe)
  * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen $X-ME-Annot-2 $HasAttachment $IsNotification $IsMailingList $NotJunk $CanUnsubscribe \*)] Ok
  * OK [UNSEEN 1221] Ok
  * OK [UIDVALIDITY 1108730350] Ok
  * OK [UIDNEXT 2231] Ok
  * OK [HIGHESTMODSEQ 40306873] Ok
  * OK [MAILBOXID (210306ee-5833-456b-bede-6d04757128b3)] Ok
  * OK [URLMECH INTERNAL] Ok
  * OK [ANNOTATIONS 65536] Ok
  . OK [READ-WRITE] Completed
  . FETCH 1 MODSEQ
  * OK [HIGHESTMODSEQ 40306873] CONDSTORE enabled by FETCH MODSEQ
  * 1 FETCH (MODSEQ (39570709))
  . OK Completed (0.000 sec)
And... the * operator ranges.

  . FETCH 2231:* (UID MODSEQ)
  * 1239 FETCH (UID 2230 MODSEQ (40306872))
  . OK Completed (0.001 sec)
Source: have also implemented both client and server side IMAP, and reviewed RFC9051 very closely.

Re: Ten Years of JMAP

#35

Post by jolmg »

chillfox wrote: post #27
rawkode wrote: post #22

I really wanted JMAP to work, but FastMail can't innovate on a protocol level while providing a stale and boring product. They need to motivate people to use FastMail to boost JMAP adoption and they've failed to do that for a decade. They post their 12 days of Christmas blog every year and never a new feature to be found. If you can't add shiny features to your service with a new shiny protocol that promises to break…

As one of their customers, I really appreciate that they don't upend everything all the time with pointless features. Constantly reinventing things and piling on pointless features is one of the things I dislike most about Google, their chat solution is especially egregious for this. It only causes frustration and increases the time investment required to be proficient with the products.

They have added features though. They're just not invasive. They added masked emails, for example. And if I look at the settings right now, I notice they've added customization of what swipes do.

I too like the feeling that they're stable. I guess they're just tactful with their additions.

Re: Ten Years of JMAP

#37

Post by throw0101b »

gjmveloso wrote: post #5

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.

> It would make so easier and reliable to have a single client that works really well across personal and business email accounts, for example.

Does not Thunderbird work with Gmail/Microsoft/etc? Does not Apple's Mail.app?

Re: Ten Years of JMAP

#38

Post by louis-lau »

chillfox wrote: post #29
rawkode wrote: post #26

Earlier quoted context omitted.

Then you are also fine with IMAP. No new protocol needed.

Nope, IMAP can't provide the kind of smooth reliable experience that the Fastmail mobile app provides. Now they obviously could have done it in many different ways, but I know from experience with IMAP that it can't do it. The amount of times IMAP has resulted in duplicate emails when moving mail between folders for me is enough that I eventually gave up on attempting any kind of organization back when I was last usi…

My anecdote is that that has never happened to me and all IMAP clients seem fairly stable to me. Do with that information what you will.

Re: Ten Years of JMAP

#39

Post by throw0101b »

Freak_NL wrote: post #21
AnonC wrote: post #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 JM…

If JMAP is to be successful, having support in Thunderbird is a must have first step. It's not helpful if the same party that provides the mail service provides the frontend as well. In that case you might as well leave out the open protocol and just push the browser-based client. I like Fastmail and use it because it provides a service, and does so well (which includes support you can actually reach out to and talk…

> If JMAP is to be successful, having support in Thunderbird is a must have first step. It's not helpful if the same party that provides the mail service provides the frontend as well.

And if you're going to fund development, also put it in Dovecot.

* https://en.wikipedia.org/wiki/Dovecot_(software)

It does seem to be in Cyrus, but I'm not sure what the marketshare of that software is nowadays:

* https://en.wikipedia.org/wiki/Cyrus_IMAP_server

* https://en.wikipedia.org/wiki/Comparison_of_mail_servers

Re: Ten Years of JMAP

#40

Post by jolmg »

AnonC wrote: post #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 JM…

> I don’t know why Fastmail has developed mobile apps but no desktop applications so far.

I wonder what the mobile app adds beyond what the platform-agnostic webapp already does.

Post reply on HN