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. [email protected]
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.
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.
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 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 [email protected], 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.
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.
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. ;) [email protected]
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.
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.
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.
[+] [-] novum|11 years ago|reply
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).
[+] [-] grinich|11 years ago|reply
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. [email protected]
[+] [-] spartango|11 years ago|reply
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
[+] [-] grinich|11 years ago|reply
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.
[+] [-] andyfowler|11 years ago|reply
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...
[+] [-] cheez|11 years ago|reply
[+] [-] grinich|11 years ago|reply
https://www.inboxapp.com/docs/api#threads
[+] [-] mrec|11 years ago|reply
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.
[+] [-] grinich|11 years ago|reply
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
[+] [-] lucb1e|11 years ago|reply
> 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.
[+] [-] ics|11 years ago|reply
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.
[+] [-] jonursenbach|11 years ago|reply
[+] [-] mmc|11 years ago|reply
[+] [-] grinich|11 years ago|reply
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. ;) [email protected]
[+] [-] alooPotato|11 years ago|reply
Any comparisons vs. contextIO? Do you index all the data yourselves, or proxy requests to the actual mail provider?
[+] [-] emfree|11 years ago|reply
[+] [-] grinich|11 years ago|reply
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.
[+] [-] ljoshua|11 years ago|reply
[+] [-] pfraze|11 years ago|reply
[+] [-] grinich|11 years ago|reply
[+] [-] wojcikstefan|11 years ago|reply
[+] [-] grinich|11 years ago|reply
They're written in markdown, styled with custom HTML+CSS+JS.
[+] [-] mariusz79|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] grinich|11 years ago|reply
[deleted]
[+] [-] dllthomas|11 years ago|reply
[+] [-] grinich|11 years ago|reply
[+] [-] chandrew|11 years ago|reply
[+] [-] spang|11 years ago|reply
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.