I haven't actually used either of these products, so I might be totally wrong, but....
Inbox is a separate layer on top of existing email servers. My impression is that the pain point they're addressing is, you want to build some awesome email integration app and sell it to companies, but you're looking at how complicated it would be to speak IMAP and IMAP-with-quirks and ActiveSync and the Gmail API and everything else (in order to build a high-quality integration) and that's scaring you. You can outsource that problem to Inbox, they'll make sure they get good-quality data from any email server reliably, and you just speak an HTTP API. This involves deploying a separate server which caches email. You talk to the "sync engine" over a reasonable protocol, and the sync engine takes care of talking an unreasonable protocol to wherever the data actually lives.
JMAP is an API to directly access an email store. It's something that an email provider (Fastmail, most obviously) will directly support, but it also only helps you for those providers that actually speak JMAP.
If you're an email server developer, an ISP, etc., then JMAP is cool and Inbox is not really useful -- there's not much of a point in having an email server that speaks IMAP and then also sticking a frontend to convert IMAP to something else. You might as well just make your email server speak a reasonable protocol directly.
If you're an app author, Inbox is useful today, and JMAP is only useful, maybe, if all your users are Fastmail users.
If you're an in-house developer at a large company that's running Exchange, and realistically you have no hope of getting the email admins to switch email servers (and you wouldn't want to run the email service yourself, even if they offered), JMAP is useless to you, and Inbox is super compelling.
(There is probably an argument that the Inbox "sync engine" should speak JMAP on the front end / those APIs should converge. Certainly the Inbox sync engine should speak JMAP on the back end, so Inbox can advertise support for Fastmail.)
Michael from Inbox here— a few key differences, from the horse’s mouth. :)
First of all— I want to say that we’re huge fans of Fastmail and really admire their team and focus. Rob and Neil actually came by for lunch this summer and hacked in our office for the day. We’ve discussed JMAP back and forth with them for a while, and specifically had a long thread when we added calendar endpoints to the Inbox platform. [1]
The fundamental differences between the Inbox APIs and JMAP are the kinds of applications built with them, the open source code, and the email providers supported.
The Inbox APIs are really designed to let developers access email data in non-traditional ways. Our site reads “Say goodbye to IMAP” but we’re not so much replacing IMAP, as creating a new protocol which liberates email data to a higher form. We think about email as “the database of your life” which means unconventional “clients” and access/manipulation patterns.
That’s one of the reasons we have a more REST-inspired design, whereas JMAP is closer to RPC. The Inbox API endpoints strive to represent canonical objects that developers simply treat as resources. JMAP is tailored specifically for traditional email clients, so it excels at fast operations (like archive -> reload), but compromises in other areas of simplicity and clarity IMHO.
The other main difference is code. The Inbox sync engine is open source with about 15k lines of code on GitHub.[2] You can run it yourself right now, and it works on all providers, including Fastmail! That means your users don’t need to be on any specific provider or backend. If you don’t want to run it yourself, you can use our hosted version which also includes support for enterprise environments that use Microsoft Exchange. [3]
I’ve been lurking on the IETF mailing lists for several years now, and one thing I learned is that spec documents hardly move the world forward. Developers need code that is battle tested and they can depend on. What use is a API spec if you can’t build an app with it?
The JMAP system is a great spec for FastMail’s internal mail service, and it works to power their own clients, but unless they make some drastic changes to the code and business, it’s not a platform for building 3rd party mail apps.
As an aside, I totally wish I had more time to write. I envy how prolific the Fastmail blog is these days. :) Keep up the great work Bron, Rob, Neil, and the rest!
Thanks for commenting! I agree that our APIs are orthagonal in some ways.
We definitely plan to ship open-source code for everything JMAP. I'm working on an IMAP<=>JMAP proxy, which I'm hoping to have in time for FOSDEM in February. I'll be giving a lightning talk about JMAP there.
I tell you what - that writing it taking a lot of my time! Evenings, on the train to and from work. It's not a pace we can keep up forever.
You guys are doing awesome work. Hope to catch up with you again - and hey, it will be great if you add a JMAP backend when JMAP is a bit more mature.
Worst case for FastMail, we still have an awesome API for our own backend. Best case, we help everyone else too.
Random observation -- what's up with almost 20 of the 24 'contributors' to this project mostly having made 1 edit changes to the README? Is this some kind of pervasive Github resume padding scheme that I'm just now picking up on? (it will show the repo in the "Repositories contributed to" section of your profile even for just those 1-line README edits)
As the supposed #2 contributor to the project (with 3 commits), I'd say it's far more likely that the README is simply the most visible piece of the project (or was, before the website was released today) and people contribute back typo fixes as they encounter errors.
It's possible, but it's also standard practice on github to submit even minor typos or spelling errors via a pull request, and that automatically makes you a contributor if accepted. So there's not necessarily anything nefarious going on.
By a long shot. I'd say they could start producing joints with exactly the same production lines they already have. You'd see tobacco+marijuana cigarettes too - a highly marketable combination of high and addiction.
Not only that, but there is a substantial body within countries like the United States who benefit a lot from it being legal. For instance, the for profit prisons incarcerate non-violent drug offenders. Also, law enforcement relies heavily on policies such as seizures as a source of funding. These types of institutions also have a lot to lose when it comes to drug legalization...
They are a company with real revenue that's growing and they think the publicity will sort of make up for it, so they don't end up losing too much on it.
If yc does 5 nonprofits per batch, $500k is not a lot of money.
Exactly right. It's great to see a company which is growing fast, generating real revenue and quietly establishing itself as one of the most exciting startups in the valley, giving back like this.
Note to founders - this is the kind of thing you can do when your startup makes money!
I think you're misunderstanding the word "fake" in this context. He means they are inauthentic likes, aka likes from real people who don't actually like what they're clicking the Like button on.
He specially addressed that at 05:25 into the video. And he spent $20 instead of $5. He marketed to the US, CAN, AUS, and the UK and analyzed the new likes. The likes appeared to come from fake users.
It's funny how he predicted all these stock objections to his claims of fraud in the video, and yet they all appear here in the HN thread. Let's all watch the video again shall we?
As others have noted, this is explained in the video (and made to seem super-brain-dead-obvious, at that).
Specifically, clickfarmers are liking the ads whether they have been targeted or not, in order to thwart automated detection. So you can't escape it.
So far the only way around this that I've seen mentioned in this thread is to not advertise your facebook page at all, and instead advertise links to an external page that redirects back to your facebook page.
Thank you for being one of the few logical people in this thread. People love to bring out their pitchforks, and report / downvote (or whatever it is they do here) when someone disrupts the "flow" of things.
The guy ran a poor ad. It's his fault, not Facebooks.
