Hacker News new | past | comments | ask | show | jobs | submit login
MIT And Dropbox Alums Launch Inbox, a Next-Generation Email Platform (techcrunch.com)
390 points by ThomPete on July 7, 2014 | hide | past | web | favorite | 262 comments



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


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.


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


To address the VC issue the poster and subposters are talking about:

> If you've taken VC money, haven't you already gave up that choice

> if your current VCs aren't able to change your mind, and they get angry as a result,

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

> if your current VCs aren't able to change your mind, and they get angry as a result, just their absence alone from future funding rounds

Basically, you don't know what you're talking about. Look at the VCs involved, and try to make a case for how this could work!

Fuel Capital is a $20m fund. SVAngel doesn't take board seats. Data Collective does take board seats in A rounds, but its super unlikely they have one here. Crunchfund is a small seed fund.

All of these guys are microVCs/super angels, with <=$200m funds each. They don't take board seats in seed rounds, and I would wager a significant sum that they have basically no way to affect what Inbox wants to do. If the investors get a monthly email outlining the company's performance, they would consider themselves lucky.


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.


To elaborate on this point: if your current VCs aren't able to change your mind, and they get angry as a result, just their absence alone from future funding rounds will make it nearly impossible to get other investors interested. So they basically have you by a chain.


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.


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.


I think you're actually wrong about VC goals. Yes VCs look for acquisitions, but acquisitions only really move the needle when they're really big (>$100m). Anyone acquiring for those amounts aren't going to shut the product down.


It's pretty easy to name any number of >$100M acquisitions that have been shut down. Regardless, that's only a goal of VCs: there's no shortage of VC-funded companies that have been sold for far less than $100M when they couldn't raise the next round at a palatable price.

No startup company can make a defensible claim that their product will be around for the long haul.


> It's pretty easy to name any number of >$100M acquisitions that have been shut down.

In the B2B space in the last decade? Please go ahead! Name 5 off the top of your head and I'll concede the point.

> that have been sold for far less than $100M when they couldn't raise the next round

Sure, but the question was about what VCs _want_.


Not sure where the B2B constraint came from. That's a little more challenging, because B2B companies are more likely to have revenue and enterprise sales channels, etc., worth preserving, and it's not particularly relevant to your thesis (that products from VC-backed companies are less likely to get shut down).

Still, here's a few that came to mind where the product has been shut down or changed sufficiently to be the equivalent for many customers: dMARC FeedBurner AuthenTEC Face.com TellMe Wildfire

I'm sure I could come up with a few more if I thought about it a little longer. I'm pretty sure these are all >= 100M.

Vendor reliability is a problem at all levels. If you don't have a multi-year maintenance contract, all the more so.


I don't think the point is only about the product going away. If Inbox is acquired then it's no longer 'the email company' but the whatever-the-acquirer-wants company (which may well be advertising).


They're building a platform. They can make money by charging developers a percent of revenue made from apps built on the platform. No need to charge users for email directly.


Yeah, but very few companies start with plans to be "flipped". The reality is that the failure rate of startups is very high, the exit options are few, and privacy policies generally aren't worth the digital bits they're stored on. While you may have the best of intentions (and I genuinely believe you do) it's still not enough to let me give you access to all of my e-mail. I already do this with Google; shifting my e-mail to a new service is not practical so I would simply have two companies with access to all my e-mail instead of one. I'm also suspicious what you get out of the deal: you know how it goes, if you're not paying for the product, then you are the product... At least with Google, I know and understand their intentions.

I wish you the best of luck, because this is a hard space to play in.


In that case, you should probably make a big fancy statement to that effect. It would be popular, people are very concerned about the issue of services being acquired and binned these days, it's such an obvious pattern.

If you are not legally/politically able to make such a statement, then these casual assurances are worthless, and ultimately misleading.


Your two paragraphs are logically irreconcilable. Obviously, they cannot legally or politically make a statement like "we will never get acquired." You tell them not to make that statement if they can't. But then you also tell them they should make the statement?

People need to chill. This looks like an awesome product and platform, and it doesn't seem like it will require any data lock in (you can always move your emails from place to place, and it looks like they won't necessarily even require you to store emails on their servers. Worst comes to worst, if they shut down, I imagine they would provide migration utilities.

These guys are clearly pretty smart. If someone is going to build this product, they seem like a good choice.


>Your two paragraphs are logically irreconcilable.

That's the point.


The strongest statement you can make to this effect is to preferentially take _my_ money over VC money. Words on this particular subject have been reduced to having no value with most people.


I wonder if it's possible to make that promise a legally binding contract. Of course all startups say that they won't "go away", but most of them will even if they say they won't.


While I can't think of a legal way to guarantee "not going away", you can legally guarantee a very strict privacy policy, good for 10 years counting from when the account was created. Future changes in privacy policy would not be able to cancel the 10 years promise, so any acquirer would be prevented from pushing ads. The acquirer could still kill the produce though.


You simply set aside money in an endowment fund (or other funding apparatus) and create a legal entity charged with the task of using the money in the fund to continue operations in the event the main company shuts down. Just add a clause in the legal framework of the organization which provides for the startup and handover operations, put individuals on a "board" of some sort who will begin drawing a salary when the organization is kicked into action, etc. It's not exactly rocket science.

The fact that so many companies who "plan to be around forever" haven't bothered to even think about these sorts of things indicates to me how fundamentally unseriously they take their own business.


I am confused. The fund is set up by the company itself right? So if things get so bad that the company has to shut down, BUT they have a fund big enough to keep running the company, why must they shut themselves down to tap into it? Why can't the original company simply use that money to keep operations running?


Because that's the only way to prove continuation of operations. Also notice the difference between continuing to provide services and continuing running the company as normal (which typically would involve lots os expenditures beyond the basics necessary to keep services running).


That's nice but I'm sure many people never plan to cheat on their partner until it happens either. [1]

And I'm sure that when Google was founded it never imagined things it would be doing years later at the expense of some users of it's products.

[1] People cheat of course but also people change over time with how they see the world.


As a fellow receiver of venture funding, I think you need to have more explanation than that if you want to be convincing.

You took investment money. If you're a typical startup, you plan to take more. Investors are in this for returns. VCs are in it for returns in the timeframe of their particular funds.

That you're not planning to get acquired makes it sound like you have no plan. What you really need is a plan to stay independent and sustainable forever. Which means having some sort of plan to pay off your investors. And if that isn't being acquired, then I presume that means an IPO within 10 years. That is an unlikely outcome for any startup, and personally I'd say it's especially unlikely for an infrastructure company.

As an aside, I definitely think it's possible to go after something big while planning to flip the company. However, in that case it's important to talk as if you won't be flipping the company.


Everybody has a price. It is hard to take a promise like this seriously this early. Hopefully I am proven wrong.


How can I get an inbox?


Yuuuuuup.

If you're a company that wants to prove that you actually care about providing services that customers can rely on then you need to make a financial and legal commitment to that statement. Create a legal entity tasked with carrying out continuing operations in the event that the company shuts down, set up a bond or other funding source set aside which will provide enough operating budget for operations at some level to be continued for a year or several years.


It's Sparrow all over again :[


And now I'm sad.


I don't even understand what the intention is with the scare quotes. Are they suggesting that google would claim to discontinue gmail, but not actually discontinue it?


They should add to their site that they will not, in any circumstance, ever sell out to anyone. Ever.


You mean like Oculus ?


This got people talking. It's a smart angle to get noticed and to get press.

The goal is not to beat Google, it's to not run out of money and die as a company. To that end, taking a swing at Google is a smart move.


They would have gotten exactly the same press (TechCrunch) minus that commentary. But with that commentary they instantly cloud their announcement with two immediate thoughts-

-abandonment. You know, I wasn't thinking of it, but now it's top of my mind.

-delusion. If a funded company talks about the misled motivations of others, I instantly question their self-honesty or delusion. I mean throughout this thread we see claims of not being bought out, etc. You don't take VC money if those things aren't always on the table and top of mind. The selling out already happened.

I don't think it was good at all. Instead of talking about the product or its place, people are talking about that commentary, and not in a complimentary way.

As an aside, "Inbox App" brings you to http://inboxapp.co/. There's also http://inbox.com (which is a decided two generations ago site), and then http://inboxapp.com.


Indeed, the probability of this being discontinued, if it follows normal trends, is dramatically higher than pretty much any Google product, and worse the notion that the "product is their focus" is specious: getting investment cash or a buyout is their focus, as it is with virtually all startups.

Moralizing or taking shots at competitors is a dangerous tactic when you live in a glass house.


> Moralizing or taking shots at competitors is a dangerous tactic when you live in a glass house.

Especially when you all live in the same glass house.


FWIW, inboxapp is self-hosted and under AGPL, so it's forkable.


AGPL with Contributor License Agreement, just to be crystal clear.


In fairness they're a new company and probably only have a basic view on how they're going to make money. They just licensed their core code under 'free software' so it makes sense for them to have a CLA. It will give them some flexibility as they figure out their commercial path - though I can't actually find the CLA on their site.

Anyway, in comparison good luck finding a 'free software' license for the Gmail API, or a CLA - and that's from a company that's benefited from Open Source more than any other.


Presumably you need to sign the CLA only to contribute back to the master branch.


Yep.


Is this viral like the gpl? Does the use of the inbox backend, hosted by me, require release of the full source to the entire app that uses the inbox backend? My brief reading of the agpl seems to say yes. Which makes this an interesting toy but nothing more...


Yes, the AGPL does require the release of the source of any code built on components licensed under it. Chances are they'll have a commercial license, though my salary disputes your assertion that an AGPL base can only be used as a toy - we have contracts with some of the largest companies in my country.


Yes. See Sparrow for details / confirmation.


I'm an idiot, but I'm willing to believe there are still people out there who love what they do, and would stand by it, even if Corporation X comes knocking on the door with a pot of gold.

I'd rather cheer for them and be disappointed, than dismiss them in advance and live my life perceiving the world through a cynical lens.

Huh. I didn't know I can write so dramatically. You catch my drift, though.


Well, I think everyone kind of breaks down with their "morals" or idealistic visions when presented with the word "billion". E.g. see Occulus Rift founder Palmer Lucey's posts on Reddit from years ago claiming he will never sell the company under any condition.

But a quick offer with a billion was made and just like that Oculus was Facebook's.


You know what's cooler than a billion dollars?

Tens of millions and being in charge of a company that improves lives for millions of people around the world in a way you'd love to keep heading up.


With puppies and kittens, and everyone has rainbow coloured cotton candy whenever they want.

Wake up. You don't get to do any of that when your board is stacked with VCs.


Who says you need to get VC?

First of all JOBS act Title 3 lets you do crowdfunding. And meanwhile there are old school alternatives:

Banks (older school than VC)

Actual profits (probably even older school)

Broker dealers (crowdfunding before there was crowdfunding)


The problem is, Inbox already has a BUNCH of VC's behind it. Which means a lot of people only worried about making money on the board. Unless the founders collectively agree they won't sell the company and also have a majority of shares in the company, the first big tech company that comes knocking with an offer will treated like the second coming.


Yeah, but who needs to be cool when you have a billion dollars?


I think the point the parent comments are trying to make, factually correct or not, is that it's not entirely within the control of the people/company developing the product to determine whether they accept a buy-out if they have accepted outside money. It's not cynicism to point out when people make statements they may not have the ability to back up.

Whether that's actually the case is less clear to me though, after following some of the other comments from the developers here.


Working on a problem you care deeply about with great people is already a pot of gold. It's something that money literally cannot buy, and much harder to create than than cash in one's bank account.

And as for control, maybe I should just say it explicitly: we have raised investment but are still in full control of the company (aside: it'd be nuts if we weren't at the stage), and plan to keep it that way going forward. In fact, our investors decided to invest explicitly because they believe our team is the best able to make decisions on growing a sustainable business and solving the developer platform challenges. No matter how good the VC, they obviously don't have the background+skills+focus to design APIs (and likewise shouldn't).

One of our investors likes to say, "We're in your corner, but not in your kitchen," which I've always thought framed the relationship well. I know there's lots of cynicism in the tech world with buyouts/acqui-hires and swarmy VCs, so I can understand where this reaction comes from. And unfortunately I don't have a solid rebuttal other than saying "trust me" with the test of time. Clearly that doesn't work for the HN skeptics. :/

It's also worth pointing out that not all acquisitions are terrible. Google Docs came from an acquisition. So did Google Earth. Facebook continues to run Parse, and Instagram, and Beluga via FB Messenger. Sometimes these acquisitions legitimately make sense, but I think the important thing is keeping the right people in positions to make those decisions when the time comes, and not the people who are just looking for the immediate financial return.


So, since you seem to be a developer on this -I'd like to ask:

1. If I run my own email server and do not have email addresses from yahoo, google, et al, how does this help me?

2. Is there a way to strip html off every incoming message, but retain the original intent of the formatting?

3. Is the API compatible with PGP? Can I enable PGP encryption at the server level? For example, say the client connected to the server sends unencrypted mail over the SSL encrypted connection... is there a command to automatically encrypt the message to the end user if a PGP key is found on a public server?

4. It seems, much to my surprise, that there is a push toward permanent on-line storage of email -- even though this is extremely insecure [must trust multiple unknown parties/countries/servers/continuous rule of law, etc] and prone to failure as opposed to local only storage -- is there a "local storage" option similar to pop3 for those clients that wish to store email on cheap and easily secured local drives?

5. Tons of other questions... but these are the first four I could think of...


Sure, I'll run though these. You can also ping me at mg@inboxapp.com.

1. We just started with Gmail and Yahoo, and are working to support all IMAP servers. The sync engine currently depends on the CONDSTORE extension for performance, and not all servers have that extension enabled. What server are you running yourself? Dovecot? Cyrus? I'm sure we can get it working quickly-- we just didn't want to push support for servers that we hadn't yet tested.

2. Yep, we have some stuff to do this as well as remove quoted text and signatures[0] so you deal with the "canonical" message. We've been collaborating with the folks from Mailgun on making the best MIME parsing tools.[1] However, the incoming message is always still stored on the mail provider if you need the full rfc2822-compliant version. Storing the unparsed data locally during sync would be a one line patch, so you can do that too.

3. The API doesn't have any notion of PGP/GPG. We'd rather people build clients that have GPG encryption so you don't need to store a key on the server. (Why? See Lavabit.) Inbox just makes it easy to build any app, whether that's for one for sending secure messages, one for sending sales numbers, one for triaging bug reports, etc. etc.

Note that right now the open source sync engine has NO authentication and doesn't talk in detail about security. This was completely intentional to make debugging for developers easier. Obviously you should run this behind your own firewall, VPN, etc.

4. You're exactly right with that trend. Inbox sits as a layer between hosted providers (like Gmail) and your app, providing nice API endpoints. It doesn't currently support POP3, but we'd be up for adding it, especially if someone else wrote it. (Backend providers are pretty easy to plug+play here.) But yeah, this is aiming at the much larger market of people who use hosted services like Gmail, Yahoo, Hotmail, etc.

Feel free to get in touch if you'd like to talk more about security. I recommend joining the developer Google Group[2], where we'll discuss topics like this one and more. There are clearly lots of big decisions to make when designing a platform this important, and we want to engage the developer community to get as much feedback as possible at this stage.

We've also put a lot of work into making the code readable and modular. I encourage you to check it out from GitHub and take it for a spin in a VM. It's all Python, so very hackable.

[0] I just noticed that the Mailgun folks haven't pushed live the signature extraction library that Inbox also uses. I'll ping them now. It's pretty cool, and uses a hybrid of regex and a trained machine learning classifier.

[1] https://github.com/mailgun/flanker

[2] https://groups.google.com/forum/#!forum/inbox-dev


Would it be possible to write something like an SMTP server that feeds directly into Inbox, no Dovecot/Cyrus/IMAP/POP3 required?


It might be simpler to just use a regular SMTP server and procmail or equivalent to deliver to Inbox, with fallback to local mailbox on failure to deliver, which Inbox could then sync. No need to reinvent the wheel here.


Conceivably, yes. (Though I haven't tried it.)


By all means believe and cheer. As we can observe from the sports industry, people like having things to believe in and cheer.

But if you are somebody making business decisions based on sunshine and rainbows rather than the observed failure rate of startups, then please make those decisions with your own money and your own labor.

Because otherwise, you will end up creating a bunch of cynical employees and investors.


I would be inclined to share this naive outlook. But it's email.


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.


Yeah, looks like it's a platform, a.k.a. an API around your existing email. From a business and interoperability perspective, building a platform is definitely a good move. They'll be able to create an "email App Store" for developers to publish apps built on their platform, and they can take a cut of revenue.

I imagine the play here is to 1) build the API, 2) build a pluggable skeleton of a frontend, 3) chase the enterprise for huge swaths of customers with unique email needs (hence the emphasis on Exchange servers), and 4) recruit developers with the value prop of making money building apps on the API and selling them to enterprise customers.

I suspect the final product will look more like Google apps than it will gmail. And if the API is nice, they'll get developers, who will build unique apps, which in turn will convince enterprise customers to sign on. Acquiring customers will be especially easy if it doesn't require swapping out their email backends.


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.


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.


There is no new protocol or protocol features, so no "new mail system" around. Only a REST wrapper around the same old thing. You'll still have to support old clients on the other end. As far as I can see, it's only an enabler for email app builders. Not that's a bad thing at all.

Still I would love to see people plug other protocols in. I guess that was your point. Making everything fit in the REST paradigm is anything but progress in my humble opinion.


Exactly.


I think the best way forward is to wrap IMAP instead of trying to come up with something entirely new. The ultimate goal is a better protocol but we won't get there by simply building a better protocol.


I disagree; you take the lessons learned about the old protocol and the industry itself and you build something new. If you have to include the old you'll always be tied to supporting some of the ways it works which may prevent innovation.

Naturally both of our sides are talking theoreticals so it'll be interesting to see how everything shakes out over time.


Yes, the end goal is the same for both approaches. The reason I believe providing backwards compatability for something like email is that its probably one of the oldest and heavily used protocols people rely on today.

I believe you can think of Facebook and Twitter as "new" protocols for email. It doesn't have the "open" or "distributed" nature of email but one can say that something like Diaspora did which had a terrible time gaining traction.

I don't see how you can replace email without providing some level of interoperability. I'd love to be proved wrong though.


Personally I feel like you could just offer them side-by-side until you wean off of one onto the other. But because there are no replacement protocols (at least that I know of) that have a chance to replace email who knows how feasible that is.

As a developer when I approach a system that needs to be completely redone to be improved I try to look at how to best accomplish the goals, work out an implementation then figure out how to best provide backwards compatibility because I'm always worried going the other way is going to hamper the final product. It doesn't have to but that's how my mind works.


I think we could have faster progress if we could implement new protocols without the legacy baggage of providing backwards compatibility. Just don't think that works for email.

Offering a side-by-side option is interesting. I think that might achieve the best of both worlds. I wonder how much extra engineering work and complexity that adds, if any. It might actually be lower in the long run.


True.

To start: IMAP is an asynchronous protocol. The impedance mismatch should be obvious. The roundtrips will kill any performance you could hope for.

The right way to do this would be to do what was done for most other successful protocols and put together a new RFC with best practices, and expire the old mess ASAP. Then make room for whatever calendar extensions or send-later flags you might wish for.


I'm quite sure that Context.IO does the same thing, as I've used it before (although they directly interfaced with IMAP).


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.


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.


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


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.


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?


But none of those went up against a platform which did!


The real pain point with E-mail is we're all drowning in it.


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


    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.


This is exactly why we built the Inbox API.


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.


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

Scrap push and go pull, every destination I send to is just a personalized RSS feed I create and you can poll it or not. You want to connect with unknown people, post to a mailing list. Or people can push you a pull request which you're free to ignore.

If you want something a little less ambitious, how about mandatory cryptographic authentication as a 100% requirement, no downgrading and not optional. You wanna be in the new network you will have a real (not self signed) CA issued key and you will have a keyserver with all your users valid keys in them or we aren't accepting any mail from you or your supposed users. This isn't so much new tech with new code as issuing whips and chains to the sysadmins to enforce common sense.

Want something even simpler, I assume the only reason gmail doesn't do locale / charset filtering is a patent, but if not, it seems blindingly obvious that if I don't read Korean you could filter out anything containing more than 10% Korean glyphs or entire words. This is so obvious, the reason gmail doesn't provide it today must be a patent.

It would be funny if "inbox" means literal inbox as in a remake of that "scan and email" postal mail provider but they get around postal regulations by living in a civilized .gov or by not handling mail (they eat interoffice paper spam, which is admittedly a dying product, I haven't gotten a genuine paper memo in many years) Perhaps if you recall the anecdote from snow crash where the fedgov employee had her email reading habits tracked in detail, they could sell this to HR for sending HR-spam.


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.

Postage. Solve the spam problem with economics. Can't be done with SMTP.


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


Curious about this as well.

Clickable link: http://context.io/


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.


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.


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.


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


There's an RFC for that...

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.


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.


Not only that, but one of the partners here (Dropbox) has, calling the shots on their board, a notorious war criminal and warrantless wiretapping apologist, one Condoleeza Rice.

If you use this service, and if you don't think your mails are winding up in plain text in an NSA datacenter somewhere, you're a damn fool.


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


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.


I've seen this argument before, and, while it's true to some extent, it seems like FUD to me. The same exact argument could be used for every single server you host yourself. But how many people here have an AWS machine running HTTP and SSH?

How many of them have been compromised by the Russian mafia?

People are so scared of email, and I just don't understand it.


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.


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


I disagree. Google has no protection against NSLs.

Check out sovereign on github: https://github.com/al3x/sovereign


Correct that Google has no protection against NSLs, but that's like saying that you should always drive your car because planes are common targets for terrorism. I'm deeply troubled by the activities of the NSA et al, but realistically you are far, far more likely to be targeted for actual harm by malicious hackers than by the NSA. Even if you are targeted by the NSA, there's a better than average chance that they'll be able to get the data you care about anyway - consider how often you send an e-mail to something that doesn't end up on a server that's vulnerable to NSLs - they can compromise you on either end of the conversation, and that's not even considering the fact that governments are out there buying zero day exploits on the open market.

My point is that taking an inherently insecure (at least with respect to data privacy) protocol like the ones we use for e-mail now and putting it on your own server (and thus taking responsibility for patching, avoiding zero days, etc) is not an answer to the problem of data privacy. The way forward in my opinion is the development of communication protocols which by their very nature are trustless. If you're just interested in protecting content, then if you're using end-to-end encryption, you could use LegitimateBankSiteNumberOne.ru as your e-mail provider and it wouldn't matter. The protocols for doing this are already well-known, it's just a matter of adopting them.


I believe he was looking from the view point of an end user, not the developer integrating with Inbox. To be honest his reaction was exactly the same as mine - I wouldn't really want to use any service that uses Inbox, because now all my email has been synchronized to some other third-party service.


Because self-hosting a mail service is totally something my mom can do...

(As the sibling comment notes, I'm talking from the perspective of the end user, not that of a technologist. We need to remember who we're ultimately building these things for...)


So your theoretical (straw man) user cares enough to not want their email in the hands of a third party service provider, but is unwilling to run their own service? Maybe this user should deliver their messages by hand directly to the recipient, because their demands are unrealistic.

Self-hosted services are a significant step forward from the corporate trap of the 2000s. Offering paid hosting plans is the most logical, sustainable revenue source for the companies writing this software.


You consider both third party hosting and self hosting to unacceptable?


No, I consider anything where step N involves "go to Github..." a non-starter for anyone who's not already a technologist. Self-hosted is great — in the world Snowden has demonstrated we live in, it's probably the best solution — but it needs to be turn-key, "plug it in and enter a username/password and you're done" level of effort, or it will never become widely used.


It's open source, so someone could easily build a simple installer.


I imagine statements like yours are why Google has the user base it does.

[Sscene. PM_Tech has phoned his truck driver father]

"*Yes Dad; just build a simple installer to get an email address. An email address...it's like a phone number but letters instead. You know...so the cable company can message you. Well I suppose you could just call them...I don't know, it might take a while to build. You will have to learn programming for a start. I know you are 56. Yes, it will cut into your time for watching sports. I know I am "good" at that "computer stuff" but some guy on HN said this is how you should get an email because he knows how to do it...OK. I will be round for the game. Love to mum."

FYI Any service I have to use that starts with going to GitHUb will be ignored unless

[a] I am trying to learn something from it [b] It is 2048.


I guess the only other option is second-party hosting.


Your mum likely doesn't have the need to connect multiple email endpoints through a single API either , your mum is not the intended audience of this product as it stands.


Excuse my ignorance - how is your email not going through a third party system the minute you email someone?

Are you emailing yourself on a self hosted, air-gapped system?

If you email me for instance, Google has your email shrug.


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


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


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


Yes, for caching+performance reasons.


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.


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


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.


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.


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.


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?


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.


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


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


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.


Free as in freedom. It's AGPL.

https://www.github.com/inboxapp/inbox


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.


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


This is the first thing I thought of too. I have no idea why anyone in their right mind would even consider using their service for anything other than sending cat pics or as a spam mailbox


Yep. A "Software as a service" hosted email system is not "next generation". It's last year's thinking.


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.


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.


> Pull model rather than push model

How would someone know to pull from you? Or is every email server (or whatever we're calling it) pulling from every other server all of the time?

If your theory is that everyone in the whole world pulls from your specific service, then that kind of contradicts your whole "open source replacement to email" model.

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

So you're depending on the remote party to AV scan incoming attachments? Seems flawed.

> Better filtering

How? What tech' is in place to make filtering easier/better.


If your theory is that everyone in the whole world pulls from your specific service

Think pull as in twitter - as in the recipient controls who can send to their stream. Email is currently completely open to any spammer/idiot to spam your stream of incoming messages - for most people and most email addresses that is suboptimal. Many internal addresses do not require everyone in the world to reach them without permission, and many orgs could have just one point of contact which anyone can push to and leave the rest to be by permission only.

So you're depending on the remote party to AV scan incoming attachments? Seems flawed.

Scanning email attachments is flawed.

What tech' is in place to make filtering easier/better.

Bayesian filtering not just for spam but for all messages, filtering by person/org etc etc. Sometimes possible with fiddling today but email clients and the protocol itself could clearly be much improved.

I do think the suggestions of encryption and verified identity are more important than any of the above though, which would require fixing the email protocols.


Shameless plug: I'm working on such a system right now. It gives you the security of PGP, but makes key management transparent to the user without compromising security. The gist is that we designed an automatic key distribution and revocation algorithm that requires an adversary to compromise a bunch of different user-chosen services to break it. The (alpha) white-paper is at [1], poster (USENIX ATC 2014) is at [2], and the source code is at [3]. Also, the design is transparently backwards-compatible with IMAP.

[1] https://www.cs.princeton.edu/~jcnelson/steak-whitepaper.pdf

[2] https://github.com/jcnelson/syndicatemail/blob/master/papers...

[3] https://github.com/jcnelson/syndicatemail


Sounds great, thanks for posting the details.


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


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


I think that's the point of the project.


The idea is that no single company or entity will be able to predict in the future what users need. Email is old, but it's far from perfect. I think a platform that lets developers today leverage their expertise on modern protocol technologies and practices is an excellent idea.


I saw this article a few days ago which covers some good things email clients could do to help improve security around phishing:

http://www.tripwire.com/state-of-security/security-awareness...

The problem is that there is a lot of information which can help technical people figure out if something is suspicious but the email clients don't use that info to help non-technical people know if something is safe.


Sending large files


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


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


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.


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

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


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.


Interestingly inbox.com seems stuck in 2003.


Email is, too, so that makes sense.


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


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.


PubSub is definitely a promising model for future APIs. This is just the beta API release, and we wanted to get feedback on the delta sync protocol first.


In the meantime, WebhookInbox is useful for making client apps able to receive webhooks.



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


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.


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


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?


Has someone tried it already? Any first impressions?


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


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

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


IMAP is difficult to develop on.

1. IMAP's base spec (RFC 3501 [1]) offloads implementation on the client rather than the server. For example, the client must be able to parse the IMAP protocol, it must have be able to create threads by searching through emails, it needs to implement the logic for syncing, ... etc.

2. There are many IMAP extensions to patch the issues of the original spec [2], but implementation of these extensions across email providers is fragmented, and implementing them both server and client is plenty of work.

This is an attempt at a modern, cohesive API for email.


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.


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


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


How is using something from a TV show taking your self too seriously?


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


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


Yes.


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.



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.


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.


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.


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


Thanks! :D


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


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?


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


And for what it's worth (especially considering all that you've mentioned), email is still often quite fast.


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


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


It is?

I've routinely used email like an IM system with folks in different companies. GMail will spool email in <30 seconds. Exchange can be near instantaneous.


My gmail email regularly doesn't make it to my inbox until more than 10 minutes after it has been sent. It fucking blows.


FYI: If you have "Undo" enabled there is a delay on sending outgoing email from Gmail.


I'm glad we picked Office 365 over Goog


The short answer is that (1) email wasn't designed to be instantaneous, and (2) it uses a distributed protocol.

One of our goals is to make transit as fast as possible. But there's a limit to what Inbox can do right now since it works on top of existing providers, like Gmail or Yahoo! Mail.


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


I wish this app had more support for PGP


So, does it work with IMAP & POP?


Hi there, Christine from Inbox here.

Inbox integrates with your existing email accounts---we connect to the provider via IMAP, and provide a nice REST API on top of that. We don't support POP right now, but there's no reason we couldn't if there is demand.


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


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


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.


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


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

And we (gwillen and anyone who agrees with his comment, myself included) are just a few hackers who are tired of having the rug pulled under their feet when $CORP inevitably comes with the big bucks and all claims made by the founders in the early days of the company mysteriously disappear from the homepage.

Talk is cheap.


I like to think that shipping code is the best argument.

https://github.com/inboxapp/inbox

But yeah, I totally understand the lousy feeling of being burned when $STARTUP gets acquired or shut down.

Wish I could say more to quell your concerns. We're just going to keep working on this every day to earn respect from developers. We don't take it lightly.

/edit


Easiest way to earn the kind of respect you're after is to only make claims you can visibly and tangibly support. You cannot realistically claim you will 'never' get bought out, so don't say it.


If the code is released with an Open Source license, haven't they already met the claim? Sure the company could be bought out, but the code can't be.

Even if they were bought out the code would still be available and someone else could provide the service and continue development. Releasing the code seems like the best guarantee possible.


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

This may be part of your problem. The way I see it, IMAP and POP suckage is not a developer problem; it's a user problem. As in, users don't care that IMAP and POP suck; they only care that their email works. Most people's email works.

In other words, you can make developers as happy as clams and it won't matter, because "making developers happy" is not a sustainable business model. (Particularly if the way you are going to make them happy is to open source your toolkit and give it away for free. Not that that isn't a great thing to do: it's just not a sustainable business model.) I think a lot of the skepticism in this thread is because on some level everyone realizes this, even thought it's kind of an unpleasant truth for developers.

A sustainable business model would be: you're going to (a) convince users that, even if their email works now, it will work so much better with your new platform that they'll be amazed; and then (b) get the users to pay for that awesome service. I have seen nothing that indicates you have such a business model. Without it, I have to agree with the skeptics that, from a VC's perspective, you are far more likely to exit as an acquisition than as an IPO. Which means the VCs aren't really investing in your business, they're investing in your talent; that's what they're betting that some large company will be willing to pay for down the road, once you've demonstrated the ability to build something. But once you're acquired, you might end up building something completely different from "a better email".


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


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.


That makes sense - even if Inbox goes back on their word, there can be grandfathered-in users who have a contractual obligation from Inbox and whoever acquires/resells it.

Makes the existing user base much less valuable to possible buyers though :)


They've release the code. That's contract enough for me.


When an attack on another company's offering becomes your selling point you're bound to reap some negativity in return.


Indeed. It's pretty silly to attack another company and then go all "aw, shucks guys" when someone questions your attack. You made this an issue by making an extraordinary claim, you should stand behind your marketing.


I don't know if you'll see this comment; as far as I'm aware there's no way to passively monitor HN for replies.

But if you do see it, please check my reply to dang's comment for a thought on why I'm so angry about this.


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

Your comment is needlessly mean-spirited. The top-voted comment on the recent Show HN thread would seem to apply here: https://news.ycombinator.com/item?id=7984826


I don't think it has to be read as especially malicious. He's trying to make a point with pointed language, but it doesn't necessarily imply ill-will.


Such nuances are lost in an anonymous internet forum. It doesn't have to be read that way (what does?) but that doesn't matter—look at the effect it has had.


Moderation systems fail when they don't accept that toxicity is a human norm, pretending instead that human toxicity is an enemy to be defeated.

Why is it so wrong to criticize a bad idea? To do so bluntly?

The "effect that it had" was an honest conversation. Ultimately I find HN's policies an embarrassment and a symptom of dishonesty. Way I see it, you were brought on to make moderation more transparent, and you're doing well, but you weren't actually given powers to attack HN's main problem, which I'd define as a discomfort with disagreement.

And maybe that's a human problem. But we live in a very negative time. Outright hatred is a part of life, and tools of hatred (downvoting, shadowbanning) are hypocritically applied to shut hatred down.

But it doesn't shut it down, and it shouldn't. To say "You shouldn't feel this way" is fair game when applied as an argument between people. What you say when you banish shit is "You shouldn't exist," and that's an unsustainable mindset.

You can see the logs. You can probably see that I'm a serial offender when it comes to pissing people off here. I've got yet another account on your bad list because you think you can control discomfort.

But you don't have a modicum of transparency or honesty in your line of work, dang: there's nothing you can point to that explains why my downvoted comments are both at -4 as some minimum, but the css makes them different shades of grey.

That's really trivial shit to care about, but that's my point: you're not taking care of trivial explanation of policy. You're an improvement, but that doesn't mean you're done.


>Instead of "you're doing it wrong", suggest alternatives.


[deleted]


He obviously doesn't think it's normal. He thinks they are making abnormal claims ("we will remain available") and therefore should be prepared to make guarantees beyond normal in order for anyone to take them seriously. Sounds reasonable to me, if you think it is unreasonable, can you explain why?


I'd love to see companies whose charters legally make them impossible to acquire. No idea how this would work in practice or if you could actually make it enforceable under US law.

But I'm so sick of startups just being R&D for corporations and screwing over their userbase once they get acquired. Or even worse is companies that only get off of the ground because of user support via kickstarter or similar fund raising platforms and then get acquired.

Of course it would be much harder for those companies to raise funds but there's always bootstrapping. It'd be a big win for the consumers of the product and if marketed correctly (something like "Non-Acquirable LLC"), it could become a good way for a startup to show that they put their users first.


I'm guessing a limit on possible exits would be a red flag for investors who are looking for a return.

Having clauses with each investor that let you purchase back your shares from them at predetermined times and rates (returns would need to be healthy for them) limits their upside, but lets you buy back control whenever. - assuming you can afford it

for public companies in the US, also see "Poison pill":

http://en.wikipedia.org/wiki/Shareholder_rights_plan

http://blogs.wsj.com/moneybeat/2014/06/30/dealpolitik-poison...


Mutuals.

I was involved in setting one up at university (http://www.srcf.ucam.org/) and it's still running long past the time I had anything to do with it. I believe it's a good model for "community" internet services, by definition run in the interests of the users.

It's not impossible for one to sell out, but it requires the members (customers) to vote for it. In the case of the UK building societies, by bribing them with the capital reserves that were turned out to be essential to keeping the mortgage system running.


And the building societies that didn't sell out have since become the safe harbours in times of uncertainty i.e. Nationwide.

You'd hope there'd be a lesson in there somewhere - short term gain versus long term stability.


A worker-owned cooperative would be seemingly impossible to "acquire" since it is wholly owned, and operated, by those working in the organization. If the corporate charter does not allow outside shareholders, that would prevent the most common forms of acquisition.


> with a contractual minimum duration you promise to keep the service up, and significant monetary penalties if you fail to meet it.

Take it down a few notches, you're solution will likely not work.

This is the company's only product. If the product gets discontinued, the company is likely broke. The "significant monetary penalties" is unenforceable because the company will not have any money to fulfill the SLA penalty.


>If the product gets discontinued, the company is likely broke

Or has just been acquired, which I think is more what the parent was getting at.

>The "significant monetary penalties" is unenforceable because the company will not have any money to fulfill the SLA penalty.

The acquirer would, though!


It's a good hedge against an acquisition though. Presumably you could structure the SLA such that any acquirer would be on the hook.


I find the angry tone of this message to be misplaced and unnecessary.


Not really. If someone claims that their service will not be discontinued, unless they can offer some sort of agreement then it's worthless.

Not like they can't shutdown their company irrespective of any promises.


How about building it to be self-hosted and releasing under the AGPL license?


I also disagree with the tone but I understand the reason. They will gladly shut the service down once someone offers them enough money in aqui-hire.


    They will gladly shut the service down once someone offers them enough money in aqui-hire.
It's a bummer this is the status quo with startups. To me, it's the most disappointing thing about the tech world. I actually interviewed at other companies first, and only cofounded Inbox when I couldn't find anywhere else to solve this problem.

Probably the only convincing thing I can say is that if you wanted to build a company to flip quickly, an email infrastructure startup is certainly the most painful, masochistic way you could go about it. We spent the better part of last year reading RFCs and fixing tons of obscure bugs to get this far.


But if you don't plan to be acquired, why not sign a contract in that effect?


Greater Internet Fuckwad Theory in action. http://www.penny-arcade.com/comic/2004/03/19


Disagree. It's harsh to make a point that there is no evidence they're telling the truth, not to be edgy or get attention. It would be better without the 'shut up' but a bit of an 'angry' tone is fitting.

Really, I'm more uncomfortable with a link to a webcomic joke as an argument point...


I'm just citing where I got the 'theory.' The OP of the comment could have made their point just fine without being confrontational or 'angry' as you put it. I don't see why people are defending someone's rudeness, you can get your point across without being a jerk about it.


It's more subtle than that.

The 'shut up' detracts from the comment. Being a jerk is bad.

But being confrontational is in this case a benefit. The first line is "Your claim that your product will not be discontinued is worthless." This is confrontational in a good way, and this line is not being a jerk. It's pointing out a serious flaw without attacking anyone.


It could be phrased differently still without insinuating that what they say is worthless.

Something like, "How will you back up your claim of the product not being discontinued?" or "What will prevent your product from being discontinued?" Gets the same point across without coming off rude (it may just be me but saying "your claim ... is worthless" seems rude.) The OP of the comment definitely has a good point but it's said in a way that isn't constructive.


But that's precisely what he/she needed to insinuate. That claim is worthless to the users it's targeted towards.


Well, they release their code as AGPL ready to be self hosted. If that's not a guarantee about it not going away, I don't know what ever could be.


It's not even an argument point, but just being used as a way to call someone a name without owning it.


No it isn't. If I want to call the poster a fuckwad, I'll call him one. The only reason I linked the comic is because it may not be common knowledge to everyone where the 'theory' is from.


Then you're just poisoning the well with a bit of ad hominem (in a pretty stupid way), saying that someone else's opinion is wrong because they're anonymous when you're anonymous yourself.

Whatever it is, it's worthless.


You disingenuous bastard: "Greater Internet Fuckwad Theory in action"

You seriously don't think you called him a fuckwad?


That's the name of the 'theory' while it does imply that they're a 'fuckwad' (whatever that may be) it's not my chosen word to call them, I'm just citing it. But go ahead and defend the unnecessary rudeness and hide behind your throwaway account. I'll make it clear: The OP of the comment is being an asshole/fuckwad/douchebag/<insert word conveying sentiment here> by being needlessly rude due to the anonymity provided by having an online pseudonym.


Well, you've managed some consistency, then.

You are just as rude as the activity you're calling out. That's all I'm trying to say.


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

Please don't be aggressive like this on Hacker News. It violates the guidelines and degrades the discourse.

That sentence has no information in it—it's just rude—so the comment would be better without it.


I apologize for the unnecessarily confrontational tone of my comment.

(Because of HN's lack of comment notification system, I had no idea it was so controversial until I happened upon it again just now.)

Its significantly positive score does suggest to me, though, that there is a lot of sympathy for my position, and the angry way I stated it. In fact, it's one of my most upvoted comments. (And assuming it's received a significant number of downvotes for being unnecessarily rude, I suspect it's my most-upvoted comment of all time, in gross numbers.)

The claim that I'm complaining about is basically outright fraud, as far as I'm concerned -- they're advertising their startup as being different from other services, on the basis of having a quality they have absolutely no ability to promise (that of being guaranteed not to terminate service out from under the users without warning.) The only mitigating factor is that they are almost certainly misleading themselves as much as their users. Whether this is noble, I leave as an exercise for the reader.


Thanks. I understand your point and was not disputing it—only the tone, which violated the HN guidelines. Upvotes are not a reliable index to this. A lot of uncivil comments get heavily upvoted, unfortunately.

In some contexts, rough-and-tumble language is just fine and makes things more vigorous. Empirically, HN isn't one of those. Its system is too fragile. So if we want any high-quality discourse, we have to protect it. It's not an ethical injunction so much as a practical tradeoff.


Sorry, but I have to disagree. The sentence only has no information in it I'd you choose to blindly look at the words in a vacuum. But if you think about what he said, what he meant, the tone has a ton of information, the most obvious is a drop frustration of the empty promises and frequent shut downs that is all too common in recent startups.

I think the comment created worthwhile conversation. And I'm not sure it would be better off without it. Obviously you can disagree, and given your position perhaps my opinion doesn't really matter, but to say it has no information is just being dishonest, and I say that in the nicest way possible.


> I think the comment created worthwhile conversation.

I see two conversations here. One is about users feeling betrayed by acquisitions and whether that could be mitigated contractually. That conversation didn't require abusiveness to be created. The other conversation is about who is being a fuckwad, and hardly counts as "worthwhile". Unfortunately, it is what such rudeness leads to, and it only gets worse.

Keep in mind that we're not talking about rudeness in general. We're talking about its effect on the already precarious balance of a particular optionally-anonymous internet forum. The argument here isn't ethical so much as empirical.


" and will not be ‘discontinued’ unexpectedly."

'unexpectedly' is the key. Giving people 3-6 months of runway to say "we're shutting down on day X" is still living up to that statement.


That's not much of a feature, it's more like a common courtesy. Call me entitled, but I would expect that to be the case even without them explicitly saying so.


If it's any consolation, if I were to post something to HN, I'd appreciate this kind of brutal honesty above everything else. But I suspect I'm in the minority.


Yup. And let's not forget, that's usually for Show HN, whereas this is a full-on company release/announcement ... not the typical "check out what I made over the week/weekend" where there are bound to be more flaws by virtue of short development time.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: