[kbenson]

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.

[grinich]

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.

[me1010]

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

[grinich]

Sure, I'll run though these. You can also ping me at [e-mail].

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

[spb]

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

[kbenson]

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.

[grinich]

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