We're pretty excited about this announcement, and can't wait to see what people build with these tools. Let me know if you have any questions or feedback.
Monetization: We're going to run a hosted version (think Heroku) that developers can use instead of running their own infrastructure. No details to announce now, but feel free to email me if you'd like to join the preview beta. mg@inboxapp.com
Security/Privacy: we take this very, very seriously. I don't want to go into depth right now, but secure email storage has been a primary design goal from inception.
(Note that the open-source sync engine _explicitly_ doesn't have any security/authentication in order to make development easy.)
On the one hand, the announcement is correct that "email is here to stay" and it's exciting to see innovation on top of an ancient protocol that was never intended for the abuse it receives today (IMAP).
On the other hand, the announcement is correct that "email is here to stay" and because my entire life runs out of my inbox, I am almost certain to never grant an arbitrary third party like Inbox access to my mail. How does Inbox make money? And Inbox fully intends to store my mail; why should I trust them?
On the other other hand, I have been a long-time happy customer of Fastmail.fm and I am both amused and disappointed to see that Inbox does not support an arbitrary IMAP connection (e.g. to support Fastmail).
Michael from Inbox here. First of all, we love Fastmail and think they're great. :)
We're working hard to support any IMAP server, and it's our goal to support all providers. We just started with Gmail/Yahoo because they were the two largest services and made testing easier. IMAP is a tricky protocol to get right, with many various extensions that are not always supported or enabled.
We know we need to work to gain the trust of developers, and show that this is a product and company built by developers for developers. It's one of the reasons we decided to make the sync engine open source. Something that traditional "business school" folks would never do. We're going to keep making Inbox better and better, but the code will always be available for you to run yourself.
We're planning to release a hosted SaaS version of Inbox (think Heroku), so you don't need to host +terabytes of email data or manage sync infrastructure. We haven't announced details around that yet, but feel free to email me if you'd like access to the preview. mg@inboxapp.com
This looks like a nice API on a quick glance.
But, since this service proposes to store email data, I was hoping to find some information on the site about how they plan to make money, and what they'll do with my data when they go away or get acquired.
I know it sounds cliché, but we're not planning to "go away" or get acquired. We've always positioned this company as a long-term play, and made that clear when hiring, raising money, etc.. It's just not possible to go after something big if you plan to "flip" the company quickly.
In terms of your data, Inbox is open source so you can always run it yourself. Secondly, the mail data is still stored in your provider (Gmail, Yahoo, ...), so you wouldn't lose the primary store in any case.
However, another option to help guarantee to future is to come work on it. ;) jobs@inboxapp.com
To those who think these guys are trying to supplant the existing email protocols: they are not. They are creating (essentially) a modern "inbox" protocol. That is, it is focused on the user, not the actual delivery of email. I'd view this as a level above email.
Yep, it really focuses on the developer experience. Threads are a first-class object in the Inbox API, which is an abstraction above the existing protocols. (Although it still deals with messages under the hood.)
You can think of Inbox as a cross-provider superset of ContextIO. Also, since Inbox has its own datastore, it's a lot faster and more flexible than just proxying REST queries back to an IMAP server.
As linked by crymer11, nmh is a "mail client" of sorts that decomposes all mail actions into individual utilities that can be run from the shell. It's a bit awkward if you try to use the raw utilities directly even for your most common tasks, but a couple shell functions and/or aliases takes care of that. It's also a little bit of a pain to set up. After that, though, I've been exceedingly pleased with it.
Hi, Inbox engineer here. Beyond the contextIO feature set, we support creating drafts, sending mail, and client sync, so you can use the API to really build full-fledged mail clients. The Inbox sync engine indexes all the data, so the API's performance isn't limited by that of the mail provider.
Flipping through the documentation, the RESTful API seems to only allow for polling for new messages (deltas via the sync protocol[1]).
While I'm glad that there is a delta-API, I'm concerned that this doesn't support proper "push" notifications for new messages. This is a valuable feature of Exchange and IMAP[-IDLE](where supported).
I understand that the heterogeneity of these push protocols makes it difficult to expose a push API, but it seems an important feature of mail clients.
Similarly, it seems that REST is not quite the best protocol for the "push" piece of modern email. I suppose long-polling support on the Sync API would work fine, however.
Yep, you can set up a webhook with `*` filter criteria, but I think OP was talking about a more specific notification system for the delta sync endpoint.
Webhooks would address this challenge for a certain class of applications (those with their own server component), but if you imagine building a solid desktop email app (APNS/GCM not used), then you have a problem.
Any pushing-based API really needs to gracefully degrade to polling in case messages are lost. So we decided to first make sure the semantics of the delta sync API were great.
Under the hood we actually use features like IDLE or MS Exchange Ping, so our push updates will also be immediate. The benefit of the delta sync API is that you can query deltas (obviously), which isn't supported by IMAP.
Love the sync API. It should be easy to add long-polling support to the sync endpoint, or use the sync endpoint when any other push delivery mechanisms fail.
You might check out https://fanout.io/ which makes it easy to create realtime APIs. (disclaimer: I'm from Fanout)
If by 'we' you thought 'me', then you're absolutely right. But for my parents (for example), they're bound to be at the mercy of someone... Google is probably a better sysadmin than themselves, or myself at 3a.m. and halfway around the globe. Whether or not this is an improvement is another matter.
You mention below that this "focuses on the developer experience", but it's not clear to me what those developers are going to be developing. I really, really hope that it's not aimed at apps which badger users into granting the app access to their email; that's not something that should ever be encouraged.
You say in your reply to novum that "We know we need to work to gain the trust of developers", but developers aren't the vulnerable ones here. Users are.
One of the plans we have for the full hosted version is to create an auth flow that scopes permissions granted, kind of like how Facebook apps can only do certain things. So perhaps one app only has access to read mail from flights@virginamerica.com, and another only has the ability to create drafts but not read mail, etc.
As for what can be built on top of Inbox, it's really up to the developer. You can build a full-featured mail client, or just add a simple filter.
I see, thanks for replying! Do you use an open-source tool to generate HTML from Markdown (including the navigation bar, etc.) or have you written something custom?
38 comments
[ 4.1 ms ] story [ 126 ms ] threadWe're pretty excited about this announcement, and can't wait to see what people build with these tools. Let me know if you have any questions or feedback.
Security/Privacy: we take this very, very seriously. I don't want to go into depth right now, but secure email storage has been a primary design goal from inception.
(Note that the open-source sync engine _explicitly_ doesn't have any security/authentication in order to make development easy.)
On the one hand, the announcement is correct that "email is here to stay" and it's exciting to see innovation on top of an ancient protocol that was never intended for the abuse it receives today (IMAP).
On the other hand, the announcement is correct that "email is here to stay" and because my entire life runs out of my inbox, I am almost certain to never grant an arbitrary third party like Inbox access to my mail. How does Inbox make money? And Inbox fully intends to store my mail; why should I trust them?
On the other other hand, I have been a long-time happy customer of Fastmail.fm and I am both amused and disappointed to see that Inbox does not support an arbitrary IMAP connection (e.g. to support Fastmail).
We're working hard to support any IMAP server, and it's our goal to support all providers. We just started with Gmail/Yahoo because they were the two largest services and made testing easier. IMAP is a tricky protocol to get right, with many various extensions that are not always supported or enabled.
We know we need to work to gain the trust of developers, and show that this is a product and company built by developers for developers. It's one of the reasons we decided to make the sync engine open source. Something that traditional "business school" folks would never do. We're going to keep making Inbox better and better, but the code will always be available for you to run yourself.
We're planning to release a hosted SaaS version of Inbox (think Heroku), so you don't need to host +terabytes of email data or manage sync infrastructure. We haven't announced details around that yet, but feel free to email me if you'd like access to the preview. mg@inboxapp.com
I know it sounds cliché, but we're not planning to "go away" or get acquired. We've always positioned this company as a long-term play, and made that clear when hiring, raising money, etc.. It's just not possible to go after something big if you plan to "flip" the company quickly.
In terms of your data, Inbox is open source so you can always run it yourself. Secondly, the mail data is still stored in your provider (Gmail, Yahoo, ...), so you wouldn't lose the primary store in any case.
However, another option to help guarantee to future is to come work on it. ;) jobs@inboxapp.com
https://www.inboxapp.com/docs/api#threads
You can think of Inbox as a cross-provider superset of ContextIO. Also, since Inbox has its own datastore, it's a lot faster and more flexible than just proxying REST queries back to an IMAP server.
Any comparisons vs. contextIO? Do you index all the data yourselves, or proxy requests to the actual mail provider?
Flipping through the documentation, the RESTful API seems to only allow for polling for new messages (deltas via the sync protocol[1]).
While I'm glad that there is a delta-API, I'm concerned that this doesn't support proper "push" notifications for new messages. This is a valuable feature of Exchange and IMAP[-IDLE](where supported).
I understand that the heterogeneity of these push protocols makes it difficult to expose a push API, but it seems an important feature of mail clients.
Similarly, it seems that REST is not quite the best protocol for the "push" piece of modern email. I suppose long-polling support on the Sync API would work fine, however.
[1]: https://www.inboxapp.com/docs/api#sync-protocol
Agreed, that push is one of the more important components to a service like this.
[1]: https://github.com/inboxapp/inbox/blob/master/inbox/docs/api...
I'm glad they're thinking about it, though!
Short answer: we're working on it.
Any pushing-based API really needs to gracefully degrade to polling in case messages are lost. So we decided to first make sure the semantics of the delta sync API were great.
Under the hood we actually use features like IDLE or MS Exchange Ping, so our push updates will also be immediate. The benefit of the delta sync API is that you can query deltas (obviously), which isn't supported by IMAP.
You might check out https://fanout.io/ which makes it easy to create realtime APIs. (disclaimer: I'm from Fanout)
> With no other option, we've been at their mercy.
Lies. I have no clue what they are talking about. I'm not at anyone's mercy with my email; it's hosted right here at home.
If by 'we' you thought 'me', then you're absolutely right. But for my parents (for example), they're bound to be at the mercy of someone... Google is probably a better sysadmin than themselves, or myself at 3a.m. and halfway around the globe. Whether or not this is an improvement is another matter.
You mention below that this "focuses on the developer experience", but it's not clear to me what those developers are going to be developing. I really, really hope that it's not aimed at apps which badger users into granting the app access to their email; that's not something that should ever be encouraged.
You say in your reply to novum that "We know we need to work to gain the trust of developers", but developers aren't the vulnerable ones here. Users are.
As for what can be built on top of Inbox, it's really up to the developer. You can build a full-featured mail client, or just add a simple filter.
Check out the docs for more details. We also have SDKs for iOS and JS. https://www.inboxapp.com/docs
They're written in markdown, styled with custom HTML+CSS+JS.
The navigation bar scrolling is custom-built with AngularJS.