Inbox — The next-generation email platform | Hacker News Reader

Inbox — The next-generation email platform

inboxapp.com

61 pointsgrinich36 comments

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).

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

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

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...

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.

I'm glad they're thinking about it, though!

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.

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)

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.)

https://www.inboxapp.com/docs/api#threads

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.

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

> 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.

: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.

Well clearly you aren't their target audience.

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.

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

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?

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.

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.

Hi Michael, some exciting stuff here. Can you go more into monetization plans and privacy assurances?

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.)

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.

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

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

Thanks! :)

They're written in markdown, styled with custom HTML+CSS+JS.

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?

For going Markdown->HTML, we're just using the Python Markdown package. https://pypi.python.org/pypi/Markdown

The navigation bar scrolling is custom-built with AngularJS.

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

How's the nmh integration? :-P

nmh?

http://www.nongnu.org/nmh/

cool, I hadn't seen that before! I'll look into it.

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.

Is this similar to context.io?

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.

Reply on news.ycombinator.com