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

251–260 of 280 posts

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

#251

Post by girvo »

Dylan16807 wrote: post #68
wldcordeiro wrote: post #46

Earlier quoted context omitted.

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

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.

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

#252

Post by SideburnsOfDoom »

higherpurpose wrote: post #88

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.

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

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

#253

Post by XorNot »

grinich wrote: post #36
GrinningFool wrote: post #31

Earlier quoted context omitted.

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

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.

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

#254

Post by konzi »

The FAQ page for Inbox states "You can use Inbox to replace nearly all the functionality of IMAP and SMTP."

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

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

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

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

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

#257

Post by rdxm »

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

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

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

#258

Post by Tepix »

x1798DE wrote: post #165
unfunco wrote: post #29

Earlier quoted context omitted.

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

I disagree. Google has no protection against NSLs.

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

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

#259

Post by PM_Tech »

rosser wrote: post #16

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.

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.

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

#260

Post by pjc50 »

xorcist wrote: post #242
pjc50 wrote: post #226

Earlier quoted context omitted.

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

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

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

Post reply on HN