Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MIT And Dropbox Alums Launch Inbox, a Next-Generation Email Platform

techcrunch.com

Post reply on HN
Print view View original

211–220 of 280 posts

Re: MIT And Dropbox Alums Launch Inbox, a Next-Generation Email Platform

#211

Post by MichaelApproved »

Artemis2 wrote: post #129
MichaelApproved wrote: post #72

Earlier quoted context omitted.

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 th…

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]: h…

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.

Re: MIT And Dropbox Alums Launch Inbox, a Next-Generation Email Platform

#212

Post by xorcist »

pjc50 wrote: post #92
grinich wrote: post #25

Earlier quoted context omitted.

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

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?

Re: MIT And Dropbox Alums Launch Inbox, a Next-Generation Email Platform

#213

Post by grinich »

me1010 wrote: post #210
grinich wrote: post #203

Earlier quoted context omitted.

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 forwar…

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 serv…

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

Re: MIT And Dropbox Alums Launch Inbox, a Next-Generation Email Platform

#215

Post by thibauts »

cookiecaper wrote: post #132
BinaryIdiot wrote: post #102

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 a…

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.

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.

Re: MIT And Dropbox Alums Launch Inbox, a Next-Generation Email Platform

#216

Post by thibauts »

arihant wrote: post #202

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…

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

Re: MIT And Dropbox Alums Launch Inbox, a Next-Generation Email Platform

#217

Post by thibauts »

antjanus wrote: post #112

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 cha…

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.

Re: MIT And Dropbox Alums Launch Inbox, a Next-Generation Email Platform

#219

Post by me1010 »

thibauts wrote: post #216
arihant wrote: post #202

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…

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.

Re: MIT And Dropbox Alums Launch Inbox, a Next-Generation Email Platform

#220

Post by jude- »

grey-area wrote: post #15
boomzilla wrote: post #3

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…

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

Post reply on HN