Live data from Hacker News

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

techcrunch.com

191–200 of 280 posts

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

#191
post #50

Earlier quoted context omitted.

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

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.

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

#192
post #173

Earlier quoted context omitted.

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.

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

#193

Earlier quoted context omitted.

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

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

#194

Earlier quoted context omitted.

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.

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

#195

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.

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.

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

#196
post #62

Earlier quoted context omitted.

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.

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

#197
post #18

Earlier quoted context omitted.

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.

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.

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.

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

#198
post #83
post #50

Earlier quoted context omitted.

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

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

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

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

#199
post #196

Earlier quoted context omitted.

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?

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

#200
post #148

Earlier quoted context omitted.

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.

Post reply on HN