It will be interesting to see how this develops.<p>I've spent the last month implementing and testing IMAP support for my app [1].<p>It has... not been very fun.<p>Before we were limited to providers with a REST API, so implementing IMAP should in theory allow us to support a much wider range of email servers with a much lower support burden.<p>Although the protocol spec is tight, it seems like some providers randomly bug out or hang [2], respond with custom error messages, offer bespoke functionality [3], or generally don't comply with the spec in breaking ways [4].<p>As a result I'm more worried about this going forward than I had hoped.<p>I'll now also happily support anything that can help modernize email, so I'll apply to the developer program and will be watching JMAP closely.<p>[1]: <a href="https://leavemealone.app/" rel="nofollow">https://leavemealone.app/</a><p>[2]: Yahoo Mail always down (<a href="https://downdetector.com/status/yahoo-mail" rel="nofollow">https://downdetector.com/status/yahoo-mail</a>)<p>[3]: <a href="https://developers.google.com/gmail/imap/imap-extensions" rel="nofollow">https://developers.google.com/gmail/imap/imap-extensions</a><p>[4]: <a href="https://github.com/mscdex/node-imap/issues/775" rel="nofollow">https://github.com/mscdex/node-imap/issues/775</a>
Though I have no complaints about the way they went about implementing it (open standards hooray!), as a mail client author and someone with lots of experience with mail in general - I'm NACK to JMAP. I think that it comes with some questionable design decisions (HTTP? JSON?) which on their face I imagine look fine to the typical HNer, but in many ways is a regression from IMAP. I would prefer to see the limitations of IMAP addressed with a few carefully written extensions to the spec - which is already extensible and has a thriving set of useful extensions in the wild.<p>By no means is IMAP a particularly good protocol, but it is extremely broadly supported and designed more with email in mind than JMAP appears to be, which seems to focus more on bringing shiny web tech to email regardless of its utility in such a context. It's also one of many closely interlinked mail-related specifications, and JMAP fails to integrate well with many related specs imo.
Pretty cool protocol. I've been following this for a couple of years. I had already written a library for an earlier version of JMAP (back then references worked differently / didn’t exist); and it was interesting to see how that improved in the IETF process.
I wrote a library [1] and a POC email client for Android [2] earlier this year. It takes a moment to fully understand a now fairly complex protocol but when you get the hang of it it becomes very powerful.<p>Sadly the server support isn’t really there yet. The support for Cyrus hasn’t been released yet (you need git) and some vital functionality like push [3] is still missing. Also no word from Dovecot yet.<p>[1]: <a href="https://github.com/iNPUTmice/jmap" rel="nofollow">https://github.com/iNPUTmice/jmap</a><p>[2]: <a href="https://github.com/iNPUTmice/lttrs-android" rel="nofollow">https://github.com/iNPUTmice/lttrs-android</a><p>[3]: <a href="https://github.com/cyrusimap/cyrus-imapd/issues/2714" rel="nofollow">https://github.com/cyrusimap/cyrus-imapd/issues/2714</a>
I'm a believer in open protocols, but in recent years, I'm also loving Exchange and ActiveSync. I know that's not going to be a popular opinion here. To be honest, I don't know much about how the magic works, but the configuration is simple, the push is reliable, and everything just works. It doesn't drain my mobile and it doesn't lose its indexing and download for hours like IMAP always seems to. And besides, it's mature -- Exchange and EAS have been around for many years.<p>So here's to JMAP becoming the open standard that replaces that.
I dislike the details of JMAP’s design.<p>While I appreciate the value it brings, I can see the 5 years of struggle in the sheer size of the multiple specs needed to define some pretty rudimentary mail client/server functionality (retrieve, send, push, pagination, etc).<p>At some points they use JSON (a data format) to describe procedures... like a programming language written in JSON. It feels a bit like using a screwdriver handle as a hammer.<p>How did we end up with JMAP instead of something simpler or modular, especially with GraphQL and other similar innovations on the radar?
From what I gather it should be possible to use 2FA with JMAP. I‘m looking forward to no longer having to decide between using third-party email clients and properly securing the account that’s probably most worth securing.
One thing I find weird (probably because I’m new to JMAP and still ignorant) is having <i>position</i> AND <i>anchor</i>+<i>anchorOffset</i>. Why have both? Surely the latter is sufficient and safer (as any <i>position</i> is only guaranteed to be valid when the last response was written)? From a glance of the spec I didn’t see any explanation of why. If anyone could shed more light it’d be much appreciated.
I read imap description long time ago, and I know what it does in principle (along with issues itt), but can someone explain what value does it serve today? I have two confusing thoughts.<p>First, imap seems to be an overkill for a line wider than 64kbps. Texts do not consume much traffic and an entire mailbox can be served easily to everyone. There are some huge mailboxes out there, but messengers have this problem too and they solve it somehow (I suspect trivial &last_date=... from programming tg bots).<p>Second, and this may be due to bad clients (haven’t seen good however), imap is just sloooow. It doesn’t update instantly, but instead I have to enter every folder and pull down with my finger to update it. It can show outdated messages which I deleted on a pc <i>for ten seconds</i> before it figures out that they were deleted. My guess that it has something to do with an infinite number of roundtrips which this protocol is based on. Occasionally it shows N unread when there is none. Even push notifications fail to work properly most of the time (same server-side issues?) And with all these complications, I still have to download every attachment by finger. How come that heavy sites/forums/boards/messengers always instantly show new data and mail cannot? I know that I can simply use webmail, but wtf?<p>I’m a developer, but when I see software, I always try to evaluate it from user-only perspective. And from that, mail tech seems simply incompetent. I wish there was a port smtp->tg and tg->smtp, and special per-subj chats, so I could leave all that legacy for someone else to deal with and just talk to them without missing messages or <i>waiting</i> for updates.<p>(Not even considering mail message formatting, spam mismatches, size restrictions and non-delivery laws)
"Modern", the darling adjective of startup lingo. We thank you for your service and efficacy. It's time to abdicate the throne. All hail "more modern" the rightful heir, protector of the realm.<p>Pre-modern -> modern -> more modern -> post modern?<p>Jokes aside I enjoyed the experience of Fastmail with the exception of the migration tools. Very responsive. Kudos for submitting JMAP as an open standard.
I believe the filtering is for user-initiated search, right?<p>Would be nice to have some standardized support for sieve-like server side prefiltering. That's how I sort my mail into mailboxes, send spam (labeled elsewhere) to the spam trap, and the like.
I didn't see anything about security. I understand sending is outside the scope. But if storage and downloading is to be portable, doesn't encryption have a place?
So, how long until everything is JSON-shit over port 80 and how long until port 80 is old news and only port 443 is used for anything and everything? I can't claim to be familiar with IMAP, but it can't be worse than this garbage that requires an HTTP client and a JSON parser.<p>To process JSON, you must inspect every character, which is reason enough it's an awful ''format'' that only an ignorant could hold dear. Douglas Crockford brags about how smart he is for disallowing comments, but there's whitespace allowed everywhere. Let's not forget this asinine integer nonsense, because JavaScript lacks real integers.<p>I'm sure most people think HTTP clients and JSON parsers are standard-library affairs, nowadays, though; let's just entirely ignore matters of licensing and whatnot.<p>It's disgusting to see this as an IETF standard, but people have been complaining about how that moves along for decades; take a look at Google's robots.txt ''standard'' that doesn't do anything useful and effectively makes every existing file standard, rather than do much of anything worthwhile. The WWW and JavaScript are nothing more than a continuation of this worse-is-better filth that UNIX and C previously championed; decades ago, the IETF revised the RFC for the Finger protocol and warned about security, solely because some idiot wrote a shitty Finger server in C; now, we have useless and unnecessary standards such as this that only serve to further this next generation of idiocy.<p>I wonder when all of this will finally collapse under its own weight.
So a few years back, everything was super fast on IMAP on my phone. But now it just crawls. On the Gmail App it's still pretty fast. So I just assumed it was slow because Google was being a dick and trying to get people to use their app instead of Apple Mail or Outlook. Is the protocol slow, or is Google throttling it?
Give me the speed of fastmail with the encryption of protonmail, make the two talk to each other out of the box, and actually make something new instead of just the same old thing.<p>Actually, loan some of your devs to protonmail because both their mobile app and their imap bridge are embarrassing.
<a href="https://jmap.io/#push-mechanism" rel="nofollow">https://jmap.io/#push-mechanism</a> JMAP going to use rfc8030 push for mobile (3rd party service for notifications, really?) and EventSource (kind of http long polling) for desktop clients, as I understood. I don't like that idea, it's even worse than IMAP4 IDLE. Why not just WebSockets for mobile and desktop clients?<p>Or just building it on top of XMPP protocol (or any other chat protocol).
Super happy customer of Fastmail of 7 years now.<p>It’s a joy to use. Fast, responsive, and reliable. No pointless redesigns or 10 second loading screens like gmail.