261–270 of 280 posts
So, does it work with IMAP & POP?
Michael from Inbox here. IMAP, yes. Gmail and Yahoo! Mail now, expanding to others ASAP. (We depend on the `CONDSTORE` extensions right now for performance, which isn't always supported.) POP, no. My time machine didn't go back that far. ;) But you can help add it? github.com/inboxapp/inbox
So, does it work with IMAP & POP?
Michael from Inbox here. IMAP, yes. Gmail and Yahoo! Mail now, expanding to others ASAP. (We depend on the `CONDSTORE` extensions right now for performance, which isn't always supported.) POP, no. My time machine didn't go back that far. ;) But you can help add it? github.com/inboxapp/inbox
Imho this remark comes across as quite unprofessional. Ignoring the fact that POP and IMAP weren't born that far apart in time (wikipedia says 84 and 86 respectively), POP is one of the two standard email client retrieval protocols. Most mail clients support it for good reason.
Its no problem that inbox.io doesn't support POP3, its a feature you may or may not have it.
What bugs me, as someone who likes to implement ancient protocols and backward scompatible clients (because its the right thing to do), is your stupid remark about it. Nobody cares that you think POP3 is old fashioned and that you were too smug about it to implement it. Furthermore POP3 and IMAP are like completely different protocols for completely different use cases. I don't fucking use IMAP because its fucking centralized model doesn't make any fucking sense in my decentralized world. POP3, even being two long years older, works just fine. So don't be a dick and just say you didnt't implement it. There may be reasons, but you didn't mention one. You just bashed a perfectly fine protocol for no reason and pissed me off.
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,…
I disagree. Google has no protection against NSLs. Check out sovereign on github: https://github.com/al3x/sovereign
My point is that taking an inherently insecure (at least with respect to data privacy) protocol like the ones we use for e-mail now and putting it on your own server (and thus taking responsibility for patching, avoiding zero days, etc) is not an answer to the problem of data privacy. The way forward in my opinion is the development of communication protocols which by their very nature are trustless. If you're just interested in protecting content, then if you're using end-to-end encryption, you could use LegitimateBankSiteNumberOne.ru as your e-mail provider and it wouldn't matter. The protocols for doing this are already well-known, it's just a matter of adopting them.
Earlier quoted context omitted.
You know what's cooler than a billion dollars? Tens of millions and being in charge of a company that improves lives for millions of people around the world in a way you'd love to keep heading up.
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.
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)
Earlier quoted context omitted.
No, I consider anything where step N involves "go to Github..." a non-starter for anyone who's not already a technologist. Self-hosted is great — in the world Snowden has demonstrated we live in, it's probably the best solution — but it needs to be turn-key, "plug it in and enter a username/password and you're done" level of effort, or it will never become widely used.
It's open source, so someone could easily build a simple installer.
[Sscene. PM_Tech has phoned his truck driver father]
"*Yes Dad; just build a simple installer to get an email address. An email address...it's like a phone number but letters instead. You know...so the cable company can message you. Well I suppose you could just call them...I don't know, it might take a while to build. You will have to learn programming for a start. I know you are 56. Yes, it will cut into your time for watching sports. I know I am "good" at that "computer stuff" but some guy on HN said this is how you should get an email because he knows how to do it...OK. I will be round for the game. Love to mum."
FYI Any service I have to use that starts with going to GitHUb will be ignored unless
[a] I am trying to learn something from it [b] It is 2048.
Earlier quoted context omitted.
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 te…
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 figure out how to best provide backwards compatibility because I'm always worried going the other way is going to hamper the final product. It doesn't have to but that's how my mind works.
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.
But if you are somebody making business decisions based on sunshine and rainbows rather than the observed failure rate of startups, then please make those decisions with your own money and your own labor.
Because otherwise, you will end up creating a bunch of cynical employees and investors.
“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.
I said this in the other thread and I know it sounds cliché, but we're not planning to "go away" or get acquired or something. We've always positioned this company as a long-term play, and made that very clear when hiring, raising money, etc. It's just not possible to go after something big if you plan to "flip" the company quickly.
You took investment money. If you're a typical startup, you plan to take more. Investors are in this for returns. VCs are in it for returns in the timeframe of their particular funds.
That you're not planning to get acquired makes it sound like you have no plan. What you really need is a plan to stay independent and sustainable forever. Which means having some sort of plan to pay off your investors. And if that isn't being acquired, then I presume that means an IPO within 10 years. That is an unlikely outcome for any startup, and personally I'd say it's especially unlikely for an infrastructure company.
As an aside, I definitely think it's possible to go after something big while planning to flip the company. However, in that case it's important to talk as if you won't be flipping the company.
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,…
There's also some benefit in avoiding being part of a monoculture. Big mail providers are an enormously interesting target for both spies and criminals. Breaking into random quirky personal servers, though, has a very different cost/benefit ratio.
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…
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],…