151–160 of 280 posts
“Inbox is an email company. Google is an advertising company. This product is our focus, and will not be ‘discontinued’ unexpectedly.” Burn! Very amusing. But for all we know they will be acqui-hired, maybe even by Google, and then shifted to a different project.
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…
This may be part of your problem. The way I see it, IMAP and POP suckage is not a developer problem; it's a user problem. As in, users don't care that IMAP and POP suck; they only care that their email works. Most people's email works.
In other words, you can make developers as happy as clams and it won't matter, because "making developers happy" is not a sustainable business model. (Particularly if the way you are going to make them happy is to open source your toolkit and give it away for free. Not that that isn't a great thing to do: it's just not a sustainable business model.) I think a lot of the skepticism in this thread is because on some level everyone realizes this, even thought it's kind of an unpleasant truth for developers.
A sustainable business model would be: you're going to (a) convince users that, even if their email works now, it will work so much better with your new platform that they'll be amazed; and then (b) get the users to pay for that awesome service. I have seen nothing that indicates you have such a business model. Without it, I have to agree with the skeptics that, from a VC's perspective, you are far more likely to exit as an acquisition than as an IPO. Which means the VCs aren't really investing in your business, they're investing in your talent; that's what they're betting that some large company will be willing to pay for down the road, once you've demonstrated the ability to build something. But once you're acquired, you might end up building something completely different from "a better email".
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.
Not having full e2e encryption is an absolute deal-breaker for me. The service looks nice and I like that I can play with the code, but without encryption (especially when Inbox App offers hosted email), there's nothing to write home about, for me (and I'm sure IA solves issues other people have that I do not).
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…
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.
Naturally both of our sides are talking theoreticals so it'll be interesting to see how everything shakes out over time.
Earlier quoted context omitted.
It's on GitHub, you can self-host it if you wanted to. It's not a service yet .
Because self-hosting a mail service is totally something my mom can do... (As the sibling comment notes, I'm talking from the perspective of the end user, not that of a technologist. We need to remember who we're ultimately building these things for...)
So it's an e-mail client as an platform/SDK? That's kind of neat.
In plain english can one explain whats broken with iMap/current email and how Inbox fixes it ? I m missing something sure here
It's also hairy, slow, and a bit buggy.
Some concrete issues: https://gist.github.com/mscdex/5329227
Since everyone's using this standard, the only way forward is to either jettison the whole lot and start fresh (network effect means this will never happen), or to wrap it, maintain compatibility, and slowly get your wrapper accepted (which is at least possible in this universe).
Earlier quoted context omitted.
Because self-hosting a mail service is totally something my mom can do... (As the sibling comment notes, I'm talking from the perspective of the end user, not that of a technologist. We need to remember who we're ultimately building these things for...)
You consider both third party hosting and self hosting to unacceptable?
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…