MIT And Dropbox Alums Launch Inbox, a Next-Generation Email Platform • Hacker News Board

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

#271

Post by InclinedPlane » Tue, Jul 08, 2014, 4:51 PM UTC

xerophtye wrote: post #247

InclinedPlane wrote: post #227

Earlier quoted context omitted.

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…

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

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

#272

Post by x1798DE » Tue, Jul 08, 2014, 5:17 PM UTC

wpietri wrote: post #269

x1798DE wrote: post #165

Earlier quoted context omitted.

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

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

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

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

#273

Post by jmathai » Tue, Jul 08, 2014, 5:59 PM UTC

BinaryIdiot wrote: post #266

jmathai wrote: post #194

Earlier quoted context omitted.

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

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

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.

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

#274

Post by grey-area » Wed, Jul 09, 2014, 10:41 AM UTC

Someone1234 wrote: post #150

grey-area wrote: post #15

Earlier quoted context omitted.

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…

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

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.

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

#275

Post by timdierks » Wed, Jul 09, 2014, 8:48 PM UTC

pbiggar wrote: post #186

timdierks wrote: post #180

Earlier quoted context omitted.

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.

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

#276

Post by dhagz » Wed, Jul 09, 2014, 9:37 PM UTC

EGreg wrote: post #264

weego wrote: post #244

Earlier quoted context omitted.

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.

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

#277

Post by xorcist » Fri, Jul 11, 2014, 12:16 PM UTC

pjc50 wrote: post #260

xorcist wrote: post #242

Earlier quoted context omitted.

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…

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.

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

#278

Post by gwillen » Mon, Jul 14, 2014, 6:41 AM UTC

dang wrote: post #178

gwillen wrote: post #24

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.

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

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

#279

Post by gwillen » Mon, Jul 14, 2014, 6:42 AM UTC

grinich wrote: post #50

gwillen wrote: post #24

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

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.

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

#280

Post by dang » Mon, Jul 14, 2014, 8:14 AM UTC

gwillen wrote: post #278

dang wrote: post #178

Earlier quoted context omitted.

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

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 a moral or ethical injunction so much as a practical tradeoff.