8 ms·

Inbox — The next-generation email platform

61 points by grinich 12y ago

grinich 12y ago
Hi HN. Michael from Inbox here. 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 12y ago
  Hi Michael, some exciting stuff here. Can you go more into monetization plans and privacy assurances?
  - grinich 12y ago
    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.)
novum 12y ago
I have mixed feelings here. 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 12y ago
  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
mmc 12y ago
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.
- grinich 12y ago
  Michael from Inbox here. 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
cheez 12y ago
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.
- grinich 12y ago
  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.) https://www.inboxapp.com/docs/api#threads https://www.inboxapp.com/docs/api#threads
chandrew 12y ago
Is this similar to context.io?
- spang 12y ago
  hey there, Christine from Inbox here. 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.
dllthomas 12y ago
How's the nmh integration? :-P
- grinich 12y ago
  nmh?
  - crymer11 12y ago
    http://www.nongnu.org/nmh/ http://www.nongnu.org/nmh/
    - grinich 12y ago
      cool, I hadn't seen that before! I'll look into it.
  - dllthomas 12y ago
    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.
alooPotato 12y ago
This is great. We've used ContextIO in the past (they've been great) so good to see more ways to access user email data. Any comparisons vs. contextIO? Do you index all the data yourselves, or proxy requests to the actual mail provider?
- emfree 12y ago
  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.
spartango 12y ago
Maybe I'm missing something, but: 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 https://www.inboxapp.com/docs/api#sync-protocol
- andyfowler 12y ago
  I'm not entirely sure yet, but glancing around the docs, it seems like the way to do this is via their webhooks[1]. 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/13_webhooks.mdown https://github.com/inboxapp/inbox/blob/master/inbox/docs/api...
  - grinich 12y ago
    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.
  - spartango 12y ago
    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. I'm glad they're thinking about it, though!
- grinich 12y ago
  Michael from Inbox here. 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.
mariusz79 12y ago
Somehow I doubt that python based software will be efficient enough to deal with thousands of connections transferring gigabytes of data.
- deleted 12y ago
  [deleted]
- grinich 12y ago
  Seemed to work at Dropbox ;)
lucb1e 12y ago
> In the current email landscape, captive users are shown targeted advertisements, and interfaces are cluttered with confusing “social” services. > 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 12y ago
  :s/lies/simplistic generalization 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 12y ago
  Well clearly you aren't their target audience.
mrec 12y ago
Not sure I get it. 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 12y ago
  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. Check out the docs for more details. We also have SDKs for iOS and JS. https://www.inboxapp.com/docs https://www.inboxapp.com/docs
pfraze 12y ago
This is something I've been wanting for a while now (a self-hostable REST wrapper around email) so I'm pretty excited. Thanks guys.
- grinich 12y ago
  :) Let us know how it goes! We're in ##inbox on freenode, or at developers@inboxapp.com
wojcikstefan 12y ago
What tool are you using to generate the API docs? They look gorgeous - very clear style and convenient navigation!
- grinich 12y ago
  Thanks! :) They're written in markdown, styled with custom HTML+CSS+JS.
  - wojcikstefan 12y ago
    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?
    - grinich 12y ago
      For going Markdown->HTML, we're just using the Python Markdown package. https://pypi.python.org/pypi/Markdown https://pypi.python.org/pypi/Markdown The navigation bar scrolling is custom-built with AngularJS.

61 points by grinich 12y ago

Hi HN. Michael from Inbox here. 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 12y ago
Hi Michael, some exciting stuff here. Can you go more into monetization plans and privacy assurances?
- grinich 12y ago
  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.)

novum 12y ago

I have mixed feelings here. 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 12y ago
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

mmc 12y ago

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.

grinich 12y ago
Michael from Inbox here. 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

cheez 12y ago

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.

grinich 12y ago
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.) https://www.inboxapp.com/docs/api#threads https://www.inboxapp.com/docs/api#threads

chandrew 12y ago

Is this similar to context.io?

spang 12y ago
hey there, Christine from Inbox here. 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.

dllthomas 12y ago

How's the nmh integration? :-P

grinich 12y ago
nmh?
- crymer11 12y ago
  http://www.nongnu.org/nmh/ http://www.nongnu.org/nmh/
  - grinich 12y ago
    cool, I hadn't seen that before! I'll look into it.
- dllthomas 12y ago
  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.

alooPotato 12y ago

This is great. We've used ContextIO in the past (they've been great) so good to see more ways to access user email data. Any comparisons vs. contextIO? Do you index all the data yourselves, or proxy requests to the actual mail provider?

emfree 12y ago
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.

spartango 12y ago

Maybe I'm missing something, but: 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 https://www.inboxapp.com/docs/api#sync-protocol

andyfowler 12y ago
I'm not entirely sure yet, but glancing around the docs, it seems like the way to do this is via their webhooks[1]. 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/13_webhooks.mdown https://github.com/inboxapp/inbox/blob/master/inbox/docs/api...
- grinich 12y ago
  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.
- spartango 12y ago
  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. I'm glad they're thinking about it, though!
grinich 12y ago
Michael from Inbox here. 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.

mariusz79 12y ago

Somehow I doubt that python based software will be efficient enough to deal with thousands of connections transferring gigabytes of data.

deleted 12y ago
[deleted]
grinich 12y ago
Seemed to work at Dropbox ;)

lucb1e 12y ago

> In the current email landscape, captive users are shown targeted advertisements, and interfaces are cluttered with confusing “social” services. > 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 12y ago
:s/lies/simplistic generalization 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 12y ago
Well clearly you aren't their target audience.

mrec 12y ago

Not sure I get it. 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 12y ago
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. Check out the docs for more details. We also have SDKs for iOS and JS. https://www.inboxapp.com/docs https://www.inboxapp.com/docs

pfraze 12y ago

This is something I've been wanting for a while now (a self-hostable REST wrapper around email) so I'm pretty excited. Thanks guys.

grinich 12y ago
:) Let us know how it goes! We're in ##inbox on freenode, or at developers@inboxapp.com

wojcikstefan 12y ago

What tool are you using to generate the API docs? They look gorgeous - very clear style and convenient navigation!

grinich 12y ago
Thanks! :) They're written in markdown, styled with custom HTML+CSS+JS.
- wojcikstefan 12y ago
  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?
  - grinich 12y ago
    For going Markdown->HTML, we're just using the Python Markdown package. https://pypi.python.org/pypi/Markdown https://pypi.python.org/pypi/Markdown The navigation bar scrolling is custom-built with AngularJS.