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

41–50 of 83 posts

Re: Ten Years of JMAP

#41

Post by chillfox »

louis-lau wrote: post #38
chillfox wrote: post #29

Earlier quoted context omitted.

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.

I sometimes feel like an edge case detector.

Anyway, It has been some years since I last used IMAP. I had issues with Outlook, Thunderbird and Nylas N1 while connecting to Gmail, Exchange and Office365. It was a fairly small mailbox getting about 20k mail a year and keeping about half of that. Usually moving about 5k mail around at a time (end of year).

It got so bad that I had to get familiar enough with the IMAP protocol to make my own client program to handle deduplication overnight. Shortly after that I decided to just give up on trying to keep thinks organized.

I am in Australia and this was before the NBN, so obviously it was always on shitty connections.

Re: Ten Years of JMAP

#42

Post by jeltz »

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.

So it is just coincidence that there are zero good IMAP clients out there? I have tried a lot of clients and nobody has managed an implementstion which is works well in practice.

And it is a pretty bad query language compared to something like SQL.

Re: Ten Years of JMAP

#43

Post by chillfox »

jolmg wrote: post #35
chillfox wrote: post #27

Earlier quoted context omitted.

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.

I don't mind new features, but I do very much mind when those new features change the UI, upend how things work or just add clutter.

Not invasive is a good way of putting it, I don't mind new features that are not invasive.

Re: Ten Years of JMAP

#44

Post by hyhconito »

brongondwana wrote: post #31
hyhconito wrote: post #19

Earlier quoted context omitted.

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.

Section 3.10 of RFC8620 scares me. I know a lot about that and a lot of the complexity around that trite point is missing.

Note I've designed and built a complex messaging system that runs over HTTP over unreliable connections and run it in production for 15 years so I know what can and does go wrong.

Popcorn at the ready.

Re: Ten Years of JMAP

#45

Post by hyhconito »

Mailtemi wrote: post #18
hyhconito wrote: post #11

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?

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.

It may use less sockets but that doesn't necessarily mean less resources. Parsing JSON is expensive, especially when there are binary types interleaved in it.

Re: Ten Years of JMAP

#46

Post by pjerem »

jolmg wrote: post #40
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.

It’s the same app actually. At least on iOS.

Re: Ten Years of JMAP

#47

Post by amaccuish »

Mailtemi wrote: post #8
mcny wrote: post #4

Earlier quoted context omitted.

On the flip side, I would like to see a free of cost email provider offer JMAP as well. It could be a limited version in the sense that something like the free version only has limited storage or something but it offers the full JMAP experience ^TM or at least that's my expectation to use JMAP. How come there are no free of cost email providers that support JMAP?

You can use https://stalw.art . Compared to other email stacks, it is very easy to set up. Its support is on par with Fastmail. I develop a JMAP email app ( https://mailtemi.com ) and have run equal tests against stalw.art locally as well as Fastmail.

But there’s no calendar or contacts support with stalwart right?

Re: Ten Years of JMAP

#48

Post by ljoshua »

Unrelated to the discussion of JMAP, but I had the pleasure of helping host the mentioned Inbox Love conference, assisting Josh Baer and Jared Goralnick. That conference was such a fun one!

Targeted, focused conferences like Inbox Love, with 150ish or fewer attendees, are by far my favorite because you can actually get to know folks, ideas flow more easily, and everyone is focused on approximately the same thing. Much better than huge, multi-track conferences. We should host more of those as an industry.

Re: Ten Years of JMAP

#49

Post by Mailtemi »

amaccuish wrote: post #47
Mailtemi wrote: post #8

Earlier quoted context omitted.

You can use https://stalw.art . Compared to other email stacks, it is very easy to set up. Its support is on par with Fastmail. I develop a JMAP email app ( https://mailtemi.com ) and have run equal tests against stalw.art locally as well as Fastmail.

But there’s no calendar or contacts support with stalwart right?

Neither Fastmail's JMAP for third-party apps nor Stalw.art supports Contacts/Calendars yet. Fastmail said that it will be enabled once it passes IETF standardization. Stalw.art also mentioned they will add support after the standard is finalized.
Post reply on HN