
MIT And Dropbox Alums Launch Inbox, a Next-Generation Email Platform - ThomPete
http://techcrunch.com/2014/07/07/mit-and-dropbox-alums-launch-inbox-a-next-generation-email-platform/?utm_campaign=fb&ncid=fb
======
Agathos
_“Inbox is an email company. Google is an advertising company. This product is
our focus, and will not be ‘discontinued’ unexpectedly.” Burn!_

Very amusing. But for all we know they will be acqui-hired, maybe even by
Google, and then shifted to a different project.

~~~
grinich
I said this in the other thread and I know it sounds cliché, but we're not
planning to "go away" or get acquired or something. We've always positioned
this company as a long-term play, and made that very clear when hiring,
raising money, etc. It's just not possible to go after something big if you
plan to "flip" the company quickly.

~~~
stephen
> but we're not planning to "go away" or get acquired or something

If you've taken VC money, haven't you already gave up that choice? Despite
pretenses, the VCs are going to want: a) IPO or b) acquisition.

Since you assert b) is not your plan, do you really think you can become a
$100m/year company (IPO) by charging for something that Google/MS/everyone
else provides for free?

Perhaps I am too pessimistic (or realistic?) about VC goals/control.

~~~
logicallee
who cares what they want? If they put in the money as a minority shareholder,
their options are to follow the CEO or try to change his/her mind.

Note: they're very good at the latter.

~~~
potatolicious
Or exercise their Board powers and fire the CEO when push comes to shove.

Nobody spends millions of dollars on something to make themselves powerless in
it.

~~~
argonaut
That's what the parent poster is getting at. In SV, most founding teams retain
control after a seed financing, and many continue to retain control after a
Series A.

------
BinaryIdiot
I guess I'm a little confused here. As far as I can tell this isn't an email
platform; it's a service that wraps IMAP and POP and exposes RESTful services.

The grand claims in the text makes me think they're going to provide something
that replaces email addresses and provides a better protocol than IMAP but
that's not what's going on as far as I can tell.

Am I missing anything? I'm not trying to be an ass and IMAP and POP suck to
deal with but there are hundreds of libraries that do it with very little work
required. IMAP should certainly be replaced with something better but I don't
see a proposal for such a thing.

~~~
cookiecaper
It's the platform upon which a better email can be built. The IMAP/POP
wrappers provide backwards compatibility, so that you don't have to stop using
the old email system while the new email is built around it. At some point,
theoretically, IMAP/POP can be transparently replaced with better delivery
protocols.

~~~
BinaryIdiot
I disagree and agree.

You're right in that better protocols can be swapped out in this design
pattern and that's fine; most decent external service consuming code does this
so it makes sense in that regard.

But where I'm not convinced is in the API itself along with the location in
which we are abstracting IMAP and POP at. The abstraction you could recreate
most of what this service does with a language library so I don't really get
why making it a service is even needed in the first place especially with so
many worried about storing their data elsewhere. The API has limited ability
to do push (webhooks are only good for web applications not thick or mobile
applications) and I didn't really see how they're handling the dual
authentication required.

But as I said I didn't want to just poopoo the idea; I'm curious as to where
it goes but with version 1 I don't see what usefulness it gives me as a
developer.

------
mikeryan
You ever see those commercial restaurant spaces which seem like a good spot on
paper, but every restaurant that goes into it seems to fail?

Thats kind of how I feel about all the "We fixed email" startups. A real pain
point but one I'd never want to tackle since there doesn't seem to be one
"I've fixed it" solution.

~~~
spang
Hi there, Christine from Inbox here.

That's why we're tackling the problem from a platform level, not building one
specific product---it's obvious to us that the ways folks are using email
these days are so varied that no one thing solves them all.

A better toolset allows many different solutions.

~~~
JetSpiegel
What do you mean, "platform"? Where's the RFC?

~~~
pc
That's unfair -- not all platforms have IETF specs (iOS, Android, AWS, etc).
You might _prefer_ platforms that have proper specifications, but the presence
of one is not implicit in the term.

~~~
JetSpiegel
Walled gardens. That doesn't bode well.

Still, I understand the nitpick, it's just that there isn't a word to describe
them. Open Standards?

------
chimeracoder
> But the larger goal with Inbox is not just to offer a suite of developer
> tools, but to create a new email standard. That means, Grinich says, the
> company has to provide the fundamental infrastructure as an open source
> package.

I really am at a loss to think of something that email _as a standard_ (and
SMTP as a protocol) is lacking that requires a replacement.

There are a lot of things that I would like from an email client, but almost
all of that can be done over IMAP using an MUA, and that would allow
interoperability with literally every other email server out there, no matter
how old the software is.

Replacing e-mail (and/or SMTP) as we know it would be a change on the order of
magnitude of IPv4 → IPv6, in terms of how disruptive it would be to daily
operations and how much extra work it would require just to handle the
changeover seamlessly.

Unfortunately they don't go into too much detail with what they hope to do[0],
so I'm left with no understanding of what they want to do that's so advanced
that it requires a new standard altogether.

[0] At first glance, everything they talk about can be done using IMAP and
makes more sense to implement client-side than server-side/embedded into the
protocol.

~~~
GrinningFool

        At first glance, everything they talk about can be done 
        using IMAP and makes more sense to implement 
        client-side than server-side/embedded into the protocol
    

Take a stab at building an unicode-enabled email client that works using 90%
of available client features across any one major email provider and any one
imap OSS server. After a few months when the flow of edge-case bugs slows to a
medium roar, take a stab at allowing customers to connect to a different OSS
imap server. Then try adding support for exchange's imap.

The standards exist, but they are open to a lot of interpretation in key
areas. As a result, there are a lot of interpretations. It's a painful thing.

~~~
grinich
This is exactly why we built the Inbox API.

~~~
XorNot
So we can have yet another standard with weird quirks and edge cases, but also
that's proprietary and promises to change in breaking ways to existing email?

The world in which Inbox succeeds at anything is just a world where we have
some more webmail competitors and that's about it.

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

~~~
spang
Hi there, Christine from Inbox here.

Inbox is pretty much a superset of ContextIO. (You can also use it to send
mails, and "entire mail clients" is a supported use case.)

Unlike ContextIO, we don't proxy requests directly to the backend mail store
---we run a mail sync engine and query that instead. Lots faster and gives us
a lot more room to make future improvements. Data just has to make it into the
datastore in the right format and then it's accessible to query via the API.
:)

------
antjanus
ITT: People no longer dazzled by innovative startups that promise to not go
away any time soon, and that promise to change very old tech.

We're all being pessimists today and for a good reason. In the past several
months alone, we've been hit by plenty of companies that trumpeted, "We're not
here to get bought out!" and get bought out, and that say, "Now that we're
bought out, nothing will change!" and everything changes.

Same goes with companies that try to fix age-old broken models, "We saw how
fucked up [insert 20+ year old tech] was, so we fixed it!" but have either
slow adoption rates, or hit brick walls when trying to solve the problems that
age-old tech solved in a very messy way, or they hit the problem of not
satisfying the "core necessary features" that seem to vary from individual to
individual.

So, as far as this email platform goes I say, "Good luck!" and I hope it goes
well but I won't be surprised if in five months I'll see a post-mortem of the
company, or a "bought out" sign on their home page.

~~~
thibauts
MIT in the title made me expect something free of VC strings. Picture me
disappointed. Outcomes tend to match intentions. Money will lead us nowhere
near the network we'd dreamt about. I'm tired of all those wannabe
billionaires.

------
arihant
The problem they are trying to solve is wicked. The problem with IMAP is not
that it's awfully complicated - that would be easier to fix with a cleaner and
simpler library/SDK. The problem with IMAP is that every service provider
fucks up in implementing it in new and surprising ways.

It's very hard to write a program to work with Gmail, Yahoo and Outlook
properly without implementing their edge cases. Let alone many thousands of
other providers, and many millions of privately hosted servers.

IMAP should be fixed or replaced with something that the implementor cannot
screw easily. But that will likely never happen so I'm going to use this.

~~~
thibauts
What would prevent us from building an IMAP successor ? Genuine curiosity.

~~~
me1010
There's an RFC for that...

[http://tools.ietf.org/html/rfc2223](http://tools.ietf.org/html/rfc2223)

There's really nothing at all stopping intelligent people getting together and
"fixing" IMAP, rather than building a compatibility bridge between siloed data
gatherer A and reticent data hoarder B.

I personally have zero problems with IMAP4. I run my own server. You could
too... In fact if you and 10 friends want to each pay $2.00/month, you could
rent and share a 48GB Linode - setup your own IMAP server with CalDav and
whatever else. All secured with ssh public key only access and a free SSL cert
from startssl. So you only get 4GB of storage space each... I wouldn't see
that as much of show stopper for me or most people I know.

------
rosser
Right, so now _all_ of my email can go through some third party's systems.
That's exactly what we need in a post-Snowden world.

~~~
unfunco
It's on GitHub, you can self-host it if you wanted to. It's not a service
_yet_.

~~~
x1798DE
Self-hosting your e-mail is really not much better, from a security point of
view, than letting gmail have your e-mail. Google has some of the best
security people in the _world_ , if your mail is safe anywhere, it's safe with
Google. The problem, of course, is that Google is definitely going to try to
read your mail, use and retain your private data indefinitely.

The problem is that if you host your own e-mail server, you dramatically
increase the chances of some unpatched flaw or tiny messed up configuration
file causing the Russian mafia to get access to everything on your e-mail
server. You probably don't even particularly decrease the risk of the NSA
getting your e-mails.

This is a problem that could be fixed by new models for e-mail that utilize
encryption so that you inherently don't need to trust third parties in order
to make use of their services. Avoiding third parties entirely is very likely
impractical and unwise.

~~~
wpietri
Depends on the threat. If you host your own email, there is a whole class of
legal intrusion (persuasive cops, warrants, national security letters) that
you get to hear about if they want your archives or stuff that's encrypted on
the wire. The same applies to corrupting employees; I'm going to know if
somebody bribes my sysadmin for access, because that's me.

There's also some benefit in avoiding being part of a monoculture. Big mail
providers are an enormously interesting target for both spies and criminals.
Breaking into random quirky personal servers, though, has a very different
cost/benefit ratio.

~~~
x1798DE
I heartily agree about avoiding being part of a monoculture, there are
definite tradeoffs. The weirder your setup, the less likely you are to be
swept up in anything bulk, but the more vulnerable you are to anything
targeted. Unfortunately, it's pretty common for some quirky little open-source
project to start out relying on obscurity, then become widely adopted, putting
you in the absolute worst case scenario, since suddenly you're running high
profile software that's never been "battle tested".

------
GrinningFool

        Grinich also points out that developers can build using 
        the Inbox APIs for free, without sending email data to 
        a third-party.
    

Cool!

    
    
        In the future, however, the company will release a 
        hosted version of Inbox that will allow developers to 
        create applications without needing to also scale their 
        own infrastructure.
    

Oh...

~~~
grinich
You can totally still run it yourself. But we figure most developers won't
want to run lots and lots of servers to sync+store terabytes of mail data.
(see Heroku, AWS, etc.)

... but you can if you want. And if that sounds interesting, maybe you should
work with us? :) jobs@inboxapp.com

~~~
alexobenauer
Besides syncing to a device, inboxapp stores a copy of a person's mail data on
the server side?

~~~
grinich
Yes, for caching+performance reasons.

~~~
FreezerburnV
Do you encrypt anything in that case? Or do things in such a way that no rogue
employee of Inbox would be able to read someone's email?

I work with email currently, and one of the core mantras we have is that
nobody should be able to read the email of someone who uses our service. It's
such a personal thing with so much private information, that even the
possibility of someone being able to do that (especially when there are more
than a handful of us) is unpalatable to everyone here, to the point that we
can't do common password recovery in order to keep that information private
from us. I certainly hope you are/will take that into consideration as you
build this.

~~~
hackuser
> I work with email currently, and one of the core mantras we have is that
> nobody should be able to read the email of someone who uses our service.

Sounds wonderful. Where do you work?

------
danieldk
I hope that there will be some standardisation in these efforts. First there
was Fastmail's JMAP, then Google's announcement of extending GMail's APIs and
now this.

IMAP has a lot of shortcomings, but at least it is a standard.

That said, Inbox' approach seems nice in that it wraps a new API around
'legacy' protocols as well.

~~~
grinich
Michael from Inbox here.

I actually looked pretty closely at JMAP when it was announce. It's really
just a JavaScript wrapper around IMAP conventions. Plus, there's no way to
actually use it-- it's just a document spec.

The thing people don't realize about IMAP being a "standard" is that there are
tons of extensions, weird bugs, provider-specific edge-cases, no comprehensive
tests, no reference implementation, etc. If you mean it has an RFC, then yes
it's a standard. But actually working with it is still hellish.

We're trying to fix email from a pragmatic, developer-focused point of view.
We just want to build new apps and services without the struggle of old
protocols or dealing with character encodings. The philosophical argument can
come later when the dust settles.

~~~
pjc50
This I strongly agree with: what we want now is a RESTful JSON API for email
retrieval and querying. IMAP was hairy 20 years ago and is stuck with its
design choices forever.

But I can't see such a thing taking off unless it's Free.

~~~
xorcist
But _why_? Email does not seem RESTful to me. Not the slighest.

Read an email and then flag it as unread? Save and delete instead of move?
Batch operations that are not atomic? What happens when the connection breaks
then?

Synchronous command requests, really? IMAP solved that 20 years ago. Do we
really want a glorified POP to replace it?

What is the purpose?

~~~
pjc50
What do you mean by "does not seem RESTful"? It's a set of data. Writing a
webmail app should be more like any other CRUD app. I don't see why that
damages atomicity. Nor do I see why synchronous command requests are a
problem, this works fine for AJAX. Especially if you can issue more than one
at once. Store the mail in MongoDB or similar (possibly detatching the bodies
of large mail for storage convenience). Stop using rfc822 as the wire format.

"Move" is greatly simplified if "location" is a tag field like gmail rather
than anything to do with filesystem storage.

The purpose would be building web apps that manipulate email.

~~~
xorcist
The question is why you think a RESTful data model fits the problem. It is a
model that fits when resources are published globally, when the CRUD methods
are enough, whose purpose is to enable global caching and make hyperlinks
possible.

Pretty much none of this is true for email. You don't even want global caching
here. You want responsivity, and a rich and extensible data model.

How would you move an email? How would you control whitelisting? Spam scoring?
Folder ACLs? How would you sleep until a mailbox changes? Even if you _could_
represent these things as resources, it's going to be much more hairy than
IMAP with the performance of POP.

The evolution of email has been completely opposite of dumbing it down. Users
expect calendaring and global contact lists, and here you have the impedance
mismatch _again_. Look at the mess that is CalDAV, and that's DAV which is
much richer then REST.

Regarding asynchronous commands, I don't know what you think it has to do with
AJAX. It is the Javascript that is asynchronous in AJAX, not the HTTP
requests. Web browsers typically implement it using multiple connections. This
is a problem. Do you really want connection pooling (so a server can serve
_fewer_ clients)? No, you want an evented protocol. Such as IMAP.

And again, you probably could do it given enough work and come close to the
performance of IMAP for most end users, but why would you? It doesn't really
map to the REST architecture.

It you would rewrite your comment but s/REST/RPC/ I would not object to it. I
would just think you were from the past :).

~~~
pjc50
Are you arguing that the correct way to do webmail is to have an IMAP client
in Javascript running in the browser? I think we're talking at cross-purposes
here. Suppose I am writing a webmail client. Suppose I am doing this in the
usual modern way of writing web applications, which is to retrieve data in
JSON or XML and render it client side. I wish to retrieve some data items
called "email headers" and "email bodies". I want the backend to look as much
like a database as possible, relational or non-relational. I want the backend
to explode mime/multipart, canonicalise things as UTF-8, fix quoted-
unprintable etc. That's the application I'm aiming at. Furthermore, I'd like
to standardise the transport layer enough that people can write
interchangeable web frontends.

As far as I know IMAP itself doesn't have any features for whitelisting and
spam scoring? Nor calendaring nor global contact lists?

"Move" email specifically would be implemented as updating the "location"
table. An email would be allowed to be in multiple locations (qv gmail
labels).

~~~
xorcist
Am I that unclear? No, I'm not arguing that the correct way to do webmail is
to implement IMAP in Javascript. (How would that even work?)

I'm arguing that a RESTful implementation of the same functionality IMAP
offers would -- by necessity -- have problems with responsivity and/or
concurrency. Webmail clients should be a case in point here.

Do note that when Google implemented the GMail app for Android, they created a
protocol that looks a lot like RPC and is nowhere near REST. These people are
not stupid and if the REST architecture made sense for mail clients you would
see it reflected there.

------
higherpurpose
To me a next-gen e-mail platform is one that has _end to end encryption_
enabled by default, like say what Dark Mail is trying to achieve. Seeing how
Dropbox has never once considered to add E2E encryption for its storage
service, and how they're hired the anti-champion of privacy, Condoleezza Rice,
I'm not expecting that to happen here - ever.

~~~
mkal_tsr
The moment they announced Condoleezza Rice I closed my Dropbox account and
moved to SpiderOak (playing with OwnCloud now).

Not having full e2e encryption is an absolute deal-breaker for me. The service
looks nice and I like that I can play with the code, but without encryption (
_especially_ when Inbox App offers hosted email), there's nothing to write
home about, _for me_ (and I'm sure IA solves issues other people have that I
do not).

------
boomzilla
In my opinion, the reason no one add "features" to an email client because it
is just as fine as is. Please tell me one thing that a user (power or just
every day user) really needs that is not supported by a reasonably recent
email client? And no, every few people use emails as a todo list.

~~~
grey-area
_Please tell me one thing that a user (power or just every day user) really
needs that is not supported by a reasonably recent email client?_

Sure, here are some ideas I'd like to see:

\- Effortless encryption

\- Verified identity

\- Pull model rather than push model (like twitter, requires verified
identity, would eliminate spam and work for many email addresses which you
don't want to be public)

\- Attachments which are uploaded once, not duplicated and sent over the
network

\- Better filtering (this one isn't bad currently, but can always be improved)

\- Integration with other forms of messaging

\- Better support for public messages like mailing lists or mass mailings,
e.g. URIs for messages or parts thereof (attachments etc).

\- Single signon (get rid of passwords on websites by producing an email
replacement so awesome people use it as a central identity)

...etc. There are plenty of possibilities, and the ones at the top of this
list I think would benefit a lot of people and make things like spam a lot
harder.

I'm not sure this particular service is going to succeed (it reminds me of
app.net in that it targets developers, which is probably a bad idea for mass-
market tech), but there are _plenty_ of things we could improve about email
and email clients.

~~~
VonGuard
A lot of these are protocol changes, not necessarily client changes... And I
don't see many protocol changes coming for email...

~~~
jrlocke
Yep, totally, email is probably as good as it will ever get. Pack up the bus
guys, let's go home.

------
ProAm
Im a bit amazing that the name "Inbox" was available for a product involving
email.

~~~
Artemis2
Names are always available when you have some money to invest in buying rights
and domains.

~~~
MichaelApproved
The name is Inbox App, not Inbox. Nothing special there.

I'm willing to bet that they'll have significant problems with the name if
they try to call it just "Inbox". First, they didn't even get the inbox.com
domain, theirs is inboxapp.com. Second, they don't seem to have a trademark on
the product name as "Inbox" and I doubt that they'd get one. Third, their
company name is Inbox App, Inc., so it doesn't seem like they did anything
special in terms of buying rights or domains.

~~~
Artemis2
You are probably right about the company name, but inboxapp.com is still a
pretty good domain name. Looking at the whois record for the domain[1] shows
that it was registered in 2008. Moreover, archive.org[2] tells us that it was
parked at GoDaddy for some time, before they purchased it in 2013. So, they
probably invested a bit of money in a good domain name, yes.

[1]:
[http://whois.domaintools.com/inboxapp.com](http://whois.domaintools.com/inboxapp.com)

[2]:
[https://web.archive.org/web/20110201102718/http://inboxapp.c...](https://web.archive.org/web/20110201102718/http://inboxapp.com/)

~~~
MichaelApproved
Nice job on the research. You're right that they may have actually paid a
premium for the domain. Though, I dislike domains with words like "app" in
them as they tend to pigeonhole the product.

------
ammmir
it's great to see friendlier APIs for working with email! is Inbox intended
more for building email clients, compared to something like Switchboard
([http://switchboard.spatch.co/](http://switchboard.spatch.co/)) which is more
for processing inbound email?

any plans for a WebSocket API? seems like it would be easier to receive pushed
emails on an existing socket, than registering a webhook and then sending a
push notification out-of-band to the client to fetch new emails.

~~~
jtmoulia
Your comparison between Switchboard and Inbox is solid. Switchboard is being
used for tasks like sending "new email" push notifications to mobile clients,
or uploading attachments to dropbox. I haven't used Inbox yet, but I'm excited
to try it out.

It's great that Inbox is also built on top of IMAP. The new Gmail API is
great, but an application which takes advantage of it is locked into using
only Gmail. By building from the standard, Switchboard and Inbox are cross-
provider.

------
xkarga00
Github repo:
[https://github.com/inboxapp/inbox](https://github.com/inboxapp/inbox)

------
konzi
The FAQ page for Inbox states "You can use Inbox to replace _nearly all_ the
functionality of IMAP and SMTP."

Implying that there is some functionality of IMAP and SMTP that Inbox doesn't
handle. Thats OK. In many cases people are willing to lose some functionality
to gain other more valuable functionality.

However, nowhere on the website can I find a description of what IMAP and SMTP
functionality Inbox doesn't handle.

If I'm going to invest my time in trying out the product, it would be great to
know upfront what features it currently doesn't support.

I think the Inbox team would be better served by just being honest and saying
"Hey with Inbox you get all these awesome features, in exchange for losing
this one feature..."

------
rakoo
If this can result in more hosted email offerings, it's excellent. I'm pretty
positive a simple API + a complete documentation + OSS reference
implementations, as they exist can help achieve that.

------
kevinwang
Inbox seems like a potentially confusing name for an email-based product.

------
gnuvince
So, I really don't understand what Inbox is. From what I'm reading, it looks
like an API to access email messages: perform queries, modify them, etc. Does
that sound right?

If it is, then what are the "email applications" that require this API? To me,
the problems with email are its plain-text nature, spam and managing the vast
quantity of mail we get. Does Inbox help here?

------
martinesko36
Has someone tried it already? Any first impressions?

------
ritwikt
In plain english can one explain whats broken with iMap/current email and how
Inbox fixes it ? I m missing something sure here

~~~
Karunamon
I wouldn't say "broken", but more "stuck in its ways" since it's a huge
standard, used by everyone, and as a result, network effects (literally
everyone online uses email) keep it from being improved in any way.

It's also hairy, slow, and a bit buggy.

Some concrete issues:
[https://gist.github.com/mscdex/5329227](https://gist.github.com/mscdex/5329227)

Since everyone's using this standard, the only way forward is to either
jettison the whole lot and start fresh (network effect means this will never
happen), or to wrap it, maintain compatibility, and slowly get your wrapper
accepted (which is at least possible in this universe).

------
MikeTaylor
Not a single mention of encryption, security, PGP or GPG. In my book, that
makes it a non-starter as a new email platform in 2014.

------
marban
If you're using the USS Enterprise as one of your key visuals, you're probably
taking yourself too seriously.

~~~
grinich
To boldly go where no APIs have gone before... ;)

More seriously, we're super focused on MS Exchange support for enterprises.
Ping me if you'd like preview access to this: mg@inboxapp.com

------
SideburnsOfDoom
Unless it's dramatically more secure than current email platforms, it's not
the "next generation" of email.

Anything hosted in big shared data centres in the USA cannot be more secure.
That's last year's thinking, not "next generation".

------
athenot
Perhaps I missed it, but what's the business model? Is it the (forthcoming)
SaaS version?

~~~
grinich
Yes.

------
old-gregg
Very neat, congrats on the launch! Quick Q: are there any reference/demo
clients out there that use this sync engine?

Even though I'm probably not you target audience, but I'd love to replace
Outlook web client (and Gmail too) with something else.

~~~
grinich
Yeah definitely!

iOS: [https://github.com/inboxapp/inbox-
ios](https://github.com/inboxapp/inbox-ios)

JS/Angular:
[https://github.com/inboxapp/inbox.js](https://github.com/inboxapp/inbox.js)

Full API docs: [https://www.inboxapp.com/docs](https://www.inboxapp.com/docs)

------
hexleo
I can image how to use inbox by Google Gmail API. It's a good news for
developers. They don't need to build a email server to receive email message
or add a SMTP part, and only use one way to transmission application's data.

------
qmaxquique
Hey guys, for those who want to try the Inbox API (and don't want to install
Vbox like me), I just have installed and configured a inbox instance into a
terminal.com container! Feel free to test it and let me know what do you
think.

------
mariusz79
What's worst here is not that by using this I would be giving up all my emails
to them, but the fact that if I created an app using their SDK all my users
would unknowingly be giving up their emails to this company.

------
daigoba66
So it's an e-mail client as an platform/SDK? That's kind of neat.

~~~
grinich
Thanks! :D

------
juliangamble
I've heard "the future of email" before:
[http://techcrunch.com/2012/05/31/first-impressions-on-
fluent...](http://techcrunch.com/2012/05/31/first-impressions-on-fluent-the-
startup-promising-the-future-of-email/) This seems very similar to fluent.io -
an email startup by Dhanji Prasanna. [http://rethrick.com/#rip-
fluent](http://rethrick.com/#rip-fluent)
[http://www.businessinsider.com.au/australian-ex-googlers-
ema...](http://www.businessinsider.com.au/australian-ex-googlers-email-
fluent-2012-2)

------
arasmussen
What I would really love for someone to fix is how _slow_ email is. Why is it
so much slower to send an email than an SMS or FB message with the same
contents?

~~~
volaski
There's no free lunch. FB (Or rather, Apple and Google's Push Notification
Server they depend on) and SMS are centralized messaging systems and that's
why they can be fast, whereas email is decentralized and designed to be "good
enough", which makes it slow but as a result has other benefits that
centralized messaging systems can't have

~~~
arasmussen
I would personally much rather PAY for a centralized system that works better
than "good enough".

~~~
hnriot
Until the centralized system fails. Email is resilient and will still be
working post-apocalypse, where as, FB will probably not.

------
ajiang
Interesting choice for logo design. It's as if someone took the Dropbox logo
and shifted the camera up to an overhead shot.

------
secfirstmd
I wish this app had more support for PGP

------
Angostura
So, does it work with IMAP & POP?

~~~
grinich
Michael from Inbox here.

IMAP, yes. Gmail and Yahoo! Mail now, expanding to others ASAP. (We depend on
the `CONDSTORE` extensions right now for performance, which isn't always
supported.)

POP, no. My time machine didn't go back that far. ;)

But you can help add it? github.com/inboxapp/inbox

~~~
maddev
> POP, no. My time machine didn't go back that far. ;)

Imho this remark comes across as quite unprofessional. Ignoring the fact that
POP and IMAP weren't born that far apart in time (wikipedia says 84 and 86
respectively), POP is one of the two standard email client retrieval
protocols. Most mail clients support it for good reason.

Its no problem that inbox.io doesn't support POP3, its a feature you may or
may not have it.

What bugs me, as someone who likes to implement ancient protocols and backward
scompatible clients (because its the right thing to do), is your stupid remark
about it. Nobody cares that you think POP3 is old fashioned and that you were
too smug about it to implement it. Furthermore POP3 and IMAP are like
completely different protocols for completely different use cases. I don't
fucking use IMAP because its fucking centralized model doesn't make any
fucking sense in my decentralized world. POP3, even being two long years
older, works just fine. So don't be a dick and just say you didnt't implement
it. There may be reasons, but you didn't mention one. You just bashed a
perfectly fine protocol for no reason and pissed me off.

------
gwillen
Your claim that your product will not be discontinued is worthless.

If you're so sure of that, put your money where your mouth is, and offer an
SLA with a contractual minimum duration you promise to keep the service up,
and significant monetary penalties if you fail to meet it.

Doesn't sound like a good idea? Then shut up.

~~~
grinich
(Michael from Inbox here.)

Ouch. We're just a few hackers trying to fix broken developer tools.

Any claim is just a claim, for sure. We know that it's a long road to earn
trust of other developers. One of the (many) reasons we made the sync engine
open source was so that developers could run it on their own metal without
trusting us. Transparency is really important to us.

This is just the beta announcement of our API. I'd love to hear any comments
you have on what guaranteed level of support+performance you would need for a
hosted product. We're working on a hosted version now (so you don't _have_ to
run it yourself), and developer happiness is the #1 priority.

~~~
nawitus
But if you believe in the claim, why not sign a contract that brings some
validity to the claim?

~~~
cookiecaper
Agreed. Those kind of binding agreements are the only way you can guarantee
that something won't change immediately upon acquisition, and an interested
party may still buy your company if you have such agreements. They may just
have to wait a while to shut you down if that is indeed their plan. However, I
don't really know if that's a better alternative than just shutting down upon
acquisition, lest a false sense of security be provided to the users.

------
droz
Sure the folks at inbox.com will be amused by their choice of product name.

------
dylanz
How is this different from Context.io?

------
jmacdotorg
Ha ha! I clicked on this article's HN comments thinking "Wow, this sounds a
company ready for their Incredible Journey to begin." (c.f.
[http://ourincrediblejourney.tumblr.com](http://ourincrediblejourney.tumblr.com))
And lo, the most upvoted comments here are all expressing the same sentiment.

I do not recall before today just looking at a new company's elevator pitch
and muttering "Best wishes with the acquihire, y'all". Something subtle's
shifted in the way we perceive startups, lately...

But the above is just my observations at my own behavior. I do wish the best
for this company!

~~~
_delirium
The fact that the pitch includes a swipe at Google shutting down services kind
of invites the "yeah but are y'all a future acquihire?" counter-skepticism. I
think they could probably just have left that whole subject out of the pitch;
it's an approach to competing with Gmail via "negative advertising" that I
think has relatively little upside and opens up a can of worms. (On the other
hand, it's an obvious enough counter-swipe that I'm not sure it's helpful for
the entire HN discussion to be about it.)

~~~
amirmc
Indeed. They've inadvertently refocused attention from an otherwise
interesting discussion about problems and innovation in Email into one about
acquihires and company lifetimes. There's a PR lesson in here folks.

------
wahsd
Can someone please educate me as to what the differentiation is between past
email protocols, messaging protocols, and these types of APIs? I'm starting to
get this sense that we are just moving towards a singular communications
protocol and the name, e.g., email or chat, is simply a matter of UI design
and layout and maybe even unnecessary simulation of behaviors and actions.

------
rdxm
Sorry, but I don't see how yet another attempt at an abstraction layer on top
of the existing protocol is even remotely interesting.

It's time to move on from email as it exists in its current form, and towards
a new fundamentally secure persistent messaging model(whatever that ends up
being).

