
Inbox — The next-generation email platform - grinich
https://www.inboxapp.com/
======
novum
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
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

------
spartango
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
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...](https://github.com/inboxapp/inbox/blob/master/inbox/docs/api/13_webhooks.mdown)

~~~
spartango
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!

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

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

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

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

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

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

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

------
pfraze
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
:) Let us know how it goes! We're in ##inbox on freenode, or at
developers@inboxapp.com

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

~~~
grinich
Thanks! :)

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

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

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

------
dllthomas
How's the nmh integration? :-P

~~~
grinich
nmh?

~~~
crymer11
[http://www.nongnu.org/nmh/](http://www.nongnu.org/nmh/)

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

------
chandrew
Is this similar to context.io?

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

