Live data from Hacker News

JMAP – a better way to email

blog.fastmail.com

71–80 of 116 posts

Re: JMAP – a better way to email

#71
post #48

Earlier quoted context omitted.

Thank you for this comment. I do wonder why they simply didn't say this at the beginning of the article. I understood what they were up to purely because I'm a technical guy, but still I didn't want to actually have to watch the video -- namely because I'm deaf, and far too often there's no captions to explain what's going on so I prefer to read (and so do people at work, school, no sound etc), and it takes a lot les…

The Youtube page has the full script on it.

Thanks for the heads up. I'm not sure about others but I almost -never- click through to the YouTube page unless I was seeking for more information but in this case, I just assumed that all the info was in the article (more or less).

Re: JMAP – a better way to email

#72
post #70

I hate to be critical considering the considerable work they've put in, but I don't buy their "JMAP is actually more REST-like than most “RESTful” APIs" statement. But maybe I'm missing a whole lot. REST doesn't preclude doing multiple things in one round trip. Well it does seem JMAP is a bit more flexible when it comes to multiplexing very different actions. But the error handling doesn't seem to tell you which comm…

Each call is tagged by the client and the same tag is added to the response by the server, so you can tell exactly what error corresponds to which call.

Caching is pretty easy: you just keep a cache of each object type. The delta update mechanism means you can very accurately invalidate what you need to keep it up to date. The system is actually really flexible and a great fit for any CRUD based app; JMAP is really just a combination of a very powerful and efficient database access protocol, and the definition of some objects to represent email, contacts and calendars.

Re: JMAP – a better way to email

#73
What does this do that IMAP and SMTP don't do already?

All you need is an IMAP server, accessed from all your devices. The one that comes with Android isn't bad. Thunderbird works fine on the desktop.

You don't have to use GMail with Android; when you first power up your Android device, click "Later" when it asks for a Google login. Then delete the Google One-Time Startup app. Google won't bother you again.

Re: JMAP – a better way to email

#74
post #56
post #55

Earlier quoted context omitted.

Every time I read about Fastmail, I want to make the jump from Google Apps. However, I don't do it because of Google Drive/Docs/Spreadsheet. Any recommendation for their replacement?!

Ha. I'm the same, every time I read about them I want to make the jump - but I'm not reliant on any of those, except mail fortunately. I just haven't quite done it yet. From people I've spoken to, everyone praises Fastmail... seems like we all need that extra push.

Less than pleasant first experience. Card failed, reason never communicated clearly enough. Very slow and archaic support.

Re: JMAP – a better way to email

#75
post #73

What does this do that IMAP and SMTP don't do already? All you need is an IMAP server, accessed from all your devices. The one that comes with Android isn't bad. Thunderbird works fine on the desktop. You don't have to use GMail with Android; when you first power up your Android device, click "Later" when it asks for a Google login. Then delete the Google One-Time Startup app. Google won't bother you again.

tldr; version: It reduces the number of network roundtrips (and server overhead) needed to keep clients in sync (great for mobile) and addresses the fragmentation issue between the various server & client implementations of the sprawling IMAP protocol.

By moving to JSON and HTTP it also makes the barrier to entry a lot lower for client developers and opens up the possibility to improve speed yet further with GZIP and websockets.

All that while being able to stay compatible with legacy IMAP servers via a reference proxy provided for free by Fastmail.

Edit: Oops I've just noticed your handle so apologies for assuming you didn't read the article. I guess you've read it and still don't see the benefit. In which case would love to know why you think it's a wasted effort (personally, I think it looks like a welcome refresh).

Re: JMAP – a better way to email

#76
post #55
post #48

Earlier quoted context omitted.

Thank you for this comment. I do wonder why they simply didn't say this at the beginning of the article. I understood what they were up to purely because I'm a technical guy, but still I didn't want to actually have to watch the video -- namely because I'm deaf, and far too often there's no captions to explain what's going on so I prefer to read (and so do people at work, school, no sound etc), and it takes a lot les…

Every time I read about Fastmail, I want to make the jump from Google Apps. However, I don't do it because of Google Drive/Docs/Spreadsheet. Any recommendation for their replacement?!

I know what you mean. Fastmail sync is definitely superior to Gmail for me, and DAV support may push me over the edge to switch my domain to FM. For Google Docs etc., maybe a private cloud provider that lets you add apps--ownCloud or something like that? I'm not sure if any of them provide apps at the same level of maturity as Google's offerings, but they could work depending on your use cases.

Re: JMAP – a better way to email

#78
post #70

I hate to be critical considering the considerable work they've put in, but I don't buy their "JMAP is actually more REST-like than most “RESTful” APIs" statement. But maybe I'm missing a whole lot. REST doesn't preclude doing multiple things in one round trip. Well it does seem JMAP is a bit more flexible when it comes to multiplexing very different actions. But the error handling doesn't seem to tell you which comm…

Each call is tagged by the client and the same tag is added to the response by the server, so you can tell exactly what error corresponds to which call. Caching is pretty easy: you just keep a cache of each object type. The delta update mechanism means you can very accurately invalidate what you need to keep it up to date. The system is actually really flexible and a great fit for any CRUD based app; JMAP is really j…

Not just some objects, but different methods to access different objects, and it's those methods that implement the semantics - the base of JMAP is just an encoding for bulk RPC.

What I mean is, if tomorrow I add a file with the mediatype application/vnd.icebraining to my server, an intermediate HTTP proxy can still cache it even though it knows nothing about my format.

But if I add a new object (say, Note) to my JMAP server, along with the appropriate methods (getNotes, getNoteUpdates, etc), an intermediate JMAP server will be unable to cache them, since it needs to know the semantics of the new methods.

So frankly, I don't see how their protocol follows an uniform interface at all.

I still think it's pretty neat, though, don't take me wrong. I just want people to stop abusing REST. There's nothing wrong with RPC!

Re: JMAP – a better way to email

#79
post #55

Earlier quoted context omitted.

Every time I read about Fastmail, I want to make the jump from Google Apps. However, I don't do it because of Google Drive/Docs/Spreadsheet. Any recommendation for their replacement?!

I know what you mean. Fastmail sync is definitely superior to Gmail for me, and DAV support may push me over the edge to switch my domain to FM. For Google Docs etc., maybe a private cloud provider that lets you add apps--ownCloud or something like that? I'm not sure if any of them provide apps at the same level of maturity as Google's offerings, but they could work depending on your use cases.

Yeah. I backed sandstorm.io and been closely monitoring it. The day collaboration apps on it closes the usability gap, I will switch.

Re: JMAP – a better way to email

#80
post #3

Wasn't there a startup recently that pivoted from being a mail client into building a generalized API for interfacing with mail services like gmail/yahoo/outlook? I forgot the name but I'm super interested in efforts like this. I have the feeling the next big social network disruption is going to be leveraging e-mail in a big way. E-mail is the established quasi-p2p (it's a network of centralized services) platform t…

IMHO the big outstanding problems with email are spam and the difficulty of using public-key cryptography (both key distribution and mail client support). Write a dead-sexy mail client that makes the crypto completely invisible and uses either a public key directory or some kind of OAuth-ish thing, and you'd solve the latter. Better, if you made finding someone's public key take time and/or money, and simply refused…

If only they could make encrypted emails as transparent as encrypted SMS like Textsecure ...
Post reply on HN