MIT And Dropbox Alums Launch Inbox, a Next-Generation Email Platform
techcrunch.com
techcrunch.com
Very amusing. But for all we know they will be acqui-hired, maybe even by Google, and then shifted to a different project.
Moralizing or taking shots at competitors is a dangerous tactic when you live in a glass house.
Especially when you all live in the same glass house.
Anyway, in comparison good luck finding a 'free software' license for the Gmail API, or a CLA - and that's from a company that's benefited from Open Source more than any other.
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.
Whether that's actually the case is less clear to me though, after following some of the other comments from the developers here.
And as for control, maybe I should just say it explicitly: we have raised investment but are still in full control of the company (aside: it'd be nuts if we weren't at the stage), and plan to keep it that way going forward. In fact, our investors decided to invest explicitly because they believe our team is the best able to make decisions on growing a sustainable business and solving the developer platform challenges. No matter how good the VC, they obviously don't have the background+skills+focus to design APIs (and likewise shouldn't).
One of our investors likes to say, "We're in your corner, but not in your kitchen," which I've always thought framed the relationship well. I know there's lots of cynicism in the tech world with buyouts/acqui-hires and swarmy VCs, so I can understand where this reaction comes from. And unfortunately I don't have a solid rebuttal other than saying "trust me" with the test of time. Clearly that doesn't work for the HN skeptics. :/
It's also worth pointing out that not all acquisitions are terrible. Google Docs came from an acquisition. So did Google Earth. Facebook continues to run Parse, and Instagram, and Beluga via FB Messenger. Sometimes these acquisitions legitimately make sense, but I think the important thing is keeping the right people in positions to make those decisions when the time comes, and not the people who are just looking for the immediate financial return.
1. If I run my own email server and do not have email addresses from yahoo, google, et al, how does this help me?
2. Is there a way to strip html off every incoming message, but retain the original intent of the formatting?
3. Is the API compatible with PGP? Can I enable PGP encryption at the server level? For example, say the client connected to the server sends unencrypted mail over the SSL encrypted connection... is there a command to automatically encrypt the message to the end user if a PGP key is found on a public server?
4. It seems, much to my surprise, that there is a push toward permanent on-line storage of email -- even though this is extremely insecure [must trust multiple unknown parties/countries/servers/continuous rule of law, etc] and prone to failure as opposed to local only storage -- is there a "local storage" option similar to pop3 for those clients that wish to store email on cheap and easily secured local drives?
5. Tons of other questions... but these are the first four I could think of...
1. We just started with Gmail and Yahoo, and are working to support all IMAP servers. The sync engine currently depends on the CONDSTORE extension for performance, and not all servers have that extension enabled. What server are you running yourself? Dovecot? Cyrus? I'm sure we can get it working quickly-- we just didn't want to push support for servers that we hadn't yet tested.
2. Yep, we have some stuff to do this as well as remove quoted text and signatures[0] so you deal with the "canonical" message. We've been collaborating with the folks from Mailgun on making the best MIME parsing tools.[1] However, the incoming message is always still stored on the mail provider if you need the full rfc2822-compliant version. Storing the unparsed data locally during sync would be a one line patch, so you can do that too.
3. The API doesn't have any notion of PGP/GPG. We'd rather people build clients that have GPG encryption so you don't need to store a key on the server. (Why? See Lavabit.) Inbox just makes it easy to build any app, whether that's for one for sending secure messages, one for sending sales numbers, one for triaging bug reports, etc. etc.
Note that right now the open source sync engine has NO authentication and doesn't talk in detail about security. This was completely intentional to make debugging for developers easier. Obviously you should run this behind your own firewall, VPN, etc.
4. You're exactly right with that trend. Inbox sits as a layer between hosted providers (like Gmail) and your app, providing nice API endpoints. It doesn't currently support POP3, but we'd be up for adding it, especially if someone else wrote it. (Backend providers are pretty easy to plug+play here.) But yeah, this is aiming at the much larger market of people who use hosted services like Gmail, Yahoo, Hotmail, etc.
Feel free to get in touch if you'd like to talk more about security. I recommend joining the developer Google Group[2], where we'll discuss topics like this one and more. There are clearly lots of big decisions to make when designing a platform this important, and we want to engage the developer community to get as much feedback as possible at this stage.
We've also put a lot of work into making the code readable and modular. I encourage you to check it out from GitHub and take it for a spin in a VM. It's all Python, so very hackable.
[0] I just noticed that the Mailgun folks haven't pushed live the signature extraction library that Inbox also uses. I'll ping them now. It's pretty cool, and uses a hybrid of regex and a trained machine learning classifier.
But a quick offer with a billion was made and just like that Oculus was Facebook's.
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.
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)
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.
If you are not legally/politically able to make such a statement, then these casual assurances are worthless, and ultimately misleading.
People need to chill. This looks like an awesome product and platform, and it doesn't seem like it will require any data lock in (you can always move your emails from place to place, and it looks like they won't necessarily even require you to store emails on their servers. Worst comes to worst, if they shut down, I imagine they would provide migration utilities.
These guys are clearly pretty smart. If someone is going to build this product, they seem like a good choice.
That's the point.
I wish you the best of luck, because this is a hard space to play in.
The fact that so many companies who "plan to be around forever" haven't bothered to even think about these sorts of things indicates to me how fundamentally unseriously they take their own business.
If you've taken VC money, haven't you already gave up that choice? Despite pretenses, the VCs are going to want: a) IPO or b) acquisition.
Since you assert b) is not your plan, do you really think you can become a $100m/year company (IPO) by charging for something that Google/MS/everyone else provides for free?
Perhaps I am too pessimistic (or realistic?) about VC goals/control.
Note: they're very good at the latter.
Nobody spends millions of dollars on something to make themselves powerless in it.
No startup company can make a defensible claim that their product will be around for the long haul.
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_.
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.
> If you've taken VC money, haven't you already gave up that choice
> if your current VCs aren't able to change your mind, and they get angry as a result,
> Or exercise their Board powers and fire the CEO when push comes to shove.
> if your current VCs aren't able to change your mind, and they get angry as a result, just their absence alone from future funding rounds
Basically, you don't know what you're talking about. Look at the VCs involved, and try to make a case for how this could work!
Fuel Capital is a $20m fund. SVAngel doesn't take board seats. Data Collective does take board seats in A rounds, but its super unlikely they have one here. Crunchfund is a small seed fund.
All of these guys are microVCs/super angels, with <=$200m funds each. They don't take board seats in seed rounds, and I would wager a significant sum that they have basically no way to affect what Inbox wants to do. If the investors get a monthly email outlining the company's performance, they would consider themselves lucky.
And I'm sure that when Google was founded it never imagined things it would be doing years later at the expense of some users of it's products.
[1] People cheat of course but also people change over time with how they see the world.
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.
The goal is not to beat Google, it's to not run out of money and die as a company. To that end, taking a swing at Google is a smart move.
-abandonment. You know, I wasn't thinking of it, but now it's top of my mind.
-delusion. If a funded company talks about the misled motivations of others, I instantly question their self-honesty or delusion. I mean throughout this thread we see claims of not being bought out, etc. You don't take VC money if those things aren't always on the table and top of mind. The selling out already happened.
I don't think it was good at all. Instead of talking about the product or its place, people are talking about that commentary, and not in a complimentary way.
As an aside, "Inbox App" brings you to http://inboxapp.co/. There's also http://inbox.com (which is a decided two generations ago site), and then http://inboxapp.com.
If you're a company that wants to prove that you actually care about providing services that customers can rely on then you need to make a financial and legal commitment to that statement. Create a legal entity tasked with carrying out continuing operations in the event that the company shuts down, set up a bond or other funding source set aside which will provide enough operating budget for operations at some level to be continued for a year or several years.
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 and POP suck to deal with but there are hundreds of libraries that do it with very little work required. IMAP should certainly be replaced with something better but I don't see a proposal for such a thing.
You're right in that better protocols can be swapped out in this design pattern and that's fine; most decent external service consuming code does this so it makes sense in that regard.
But where I'm not convinced is in the API itself along with the location in which we are abstracting IMAP and POP at. The abstraction you could recreate most of what this service does with a language library so I don't really get why making it a service is even needed in the first place especially with so many worried about storing their data elsewhere. The API has limited ability to do push (webhooks are only good for web applications not thick or mobile applications) and I didn't really see how they're handling the dual authentication required.
But as I said I didn't want to just poopoo the idea; I'm curious as to where it goes but with version 1 I don't see what usefulness it gives me as a developer.
Still I would love to see people plug other protocols in. I guess that was your point. Making everything fit in the REST paradigm is anything but progress in my humble opinion.
Naturally both of our sides are talking theoreticals so it'll be interesting to see how everything shakes out over time.
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.
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.
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.
To start: IMAP is an asynchronous protocol. The impedance mismatch should be obvious. The roundtrips will kill any performance you could hope for.
The right way to do this would be to do what was done for most other successful protocols and put together a new RFC with best practices, and expire the old mess ASAP. Then make room for whatever calendar extensions or send-later flags you might wish for.
I imagine the play here is to 1) build the API, 2) build a pluggable skeleton of a frontend, 3) chase the enterprise for huge swaths of customers with unique email needs (hence the emphasis on Exchange servers), and 4) recruit developers with the value prop of making money building apps on the API and selling them to enterprise customers.
I suspect the final product will look more like Google apps than it will gmail. And if the API is nice, they'll get developers, who will build unique apps, which in turn will convince enterprise customers to sign on. Acquiring customers will be especially easy if it doesn't require swapping out their email backends.
Thats kind of how I feel about all the "We fixed email" startups. A real pain point but one I'd never want to tackle since there doesn't seem to be one "I've fixed it" solution.
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.
Still, I understand the nitpick, it's just that there isn't a word to describe them. Open Standards?
I really am at a loss to think of something that email as a standard (and SMTP as a protocol) is lacking that requires a replacement.
There are a lot of things that I would like from an email client, but almost all of that can be done over IMAP using an MUA, and that would allow interoperability with literally every other email server out there, no matter how old the software is.
Replacing e-mail (and/or SMTP) as we know it would be a change on the order of magnitude of IPv4 → IPv6, in terms of how disruptive it would be to daily operations and how much extra work it would require just to handle the changeover seamlessly.
Unfortunately they don't go into too much detail with what they hope to do[0], so I'm left with no understanding of what they want to do that's so advanced that it requires a new standard altogether.
[0] 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.
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
The standards exist, but they are open to a lot of interpretation in key areas. As a result, there are a lot of interpretations. It's a painful thing.
The world in which Inbox succeeds at anything is just a world where we have some more webmail competitors and that's about it.
Scrap push and go pull, every destination I send to is just a personalized RSS feed I create and you can poll it or not. You want to connect with unknown people, post to a mailing list. Or people can push you a pull request which you're free to ignore.
If you want something a little less ambitious, how about mandatory cryptographic authentication as a 100% requirement, no downgrading and not optional. You wanna be in the new network you will have a real (not self signed) CA issued key and you will have a keyserver with all your users valid keys in them or we aren't accepting any mail from you or your supposed users. This isn't so much new tech with new code as issuing whips and chains to the sysadmins to enforce common sense.
Want something even simpler, I assume the only reason gmail doesn't do locale / charset filtering is a patent, but if not, it seems blindingly obvious that if I don't read Korean you could filter out anything containing more than 10% Korean glyphs or entire words. This is so obvious, the reason gmail doesn't provide it today must be a patent.
It would be funny if "inbox" means literal inbox as in a remake of that "scan and email" postal mail provider but they get around postal regulations by living in a civilized .gov or by not handling mail (they eat interoffice paper spam, which is admittedly a dying product, I haven't gotten a genuine paper memo in many years) Perhaps if you recall the anecdote from snow crash where the fedgov employee had her email reading habits tracked in detail, they could sell this to HR for sending HR-spam.
Postage. Solve the spam problem with economics. Can't be done with SMTP.
Any comparisons vs. contextIO? Do you index all the data yourselves, or proxy requests to the actual mail provider?
Clickable link: http://context.io/
Inbox is pretty much a superset of ContextIO. (You can also use it to send mails, and "entire mail clients" is a supported use case.)
Unlike ContextIO, we don't proxy requests directly to the backend mail store---we run a mail sync engine and query that instead. Lots faster and gives us a lot more room to make future improvements. Data just has to make it into the datastore in the right format and then it's accessible to query via the API. :)
We're all being pessimists today and for a good reason. In the past several months alone, we've been hit by plenty of companies that trumpeted, "We're not here to get bought out!" and get bought out, and that say, "Now that we're bought out, nothing will change!" and everything changes.
Same goes with companies that try to fix age-old broken models, "We saw how fucked up [insert 20+ year old tech] was, so we fixed it!" but have either slow adoption rates, or hit brick walls when trying to solve the problems that age-old tech solved in a very messy way, or they hit the problem of not satisfying the "core necessary features" that seem to vary from individual to individual.
So, as far as this email platform goes I say, "Good luck!" and I hope it goes well but I won't be surprised if in five months I'll see a post-mortem of the company, or a "bought out" sign on their home page.
It's very hard to write a program to work with Gmail, Yahoo and Outlook properly without implementing their edge cases. Let alone many thousands of other providers, and many millions of privately hosted servers.
IMAP should be fixed or replaced with something that the implementor cannot screw easily. But that will likely never happen so I'm going to use this.
http://tools.ietf.org/html/rfc2223
There's really nothing at all stopping intelligent people getting together and "fixing" IMAP, rather than building a compatibility bridge between siloed data gatherer A and reticent data hoarder B.
I personally have zero problems with IMAP4. I run my own server. You could too... In fact if you and 10 friends want to each pay $2.00/month, you could rent and share a 48GB Linode - setup your own IMAP server with CalDav and whatever else. All secured with ssh public key only access and a free SSL cert from startssl. So you only get 4GB of storage space each... I wouldn't see that as much of show stopper for me or most people I know.
(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...)
Self-hosted services are a significant step forward from the corporate trap of the 2000s. Offering paid hosting plans is the most logical, sustainable revenue source for the companies writing this software.
[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.
The problem is that if you host your own e-mail server, you dramatically increase the chances of some unpatched flaw or tiny messed up configuration file causing the Russian mafia to get access to everything on your e-mail server. You probably don't even particularly decrease the risk of the NSA getting your e-mails.
This is a problem that could be fixed by new models for e-mail that utilize encryption so that you inherently don't need to trust third parties in order to make use of their services. Avoiding third parties entirely is very likely impractical and unwise.
How many of them have been compromised by the Russian mafia?
People are so scared of email, and I just don't understand it.
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.
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.
If you use this service, and if you don't think your mails are winding up in plain text in an NSA datacenter somewhere, you're a damn fool.
Are you emailing yourself on a self hosted, air-gapped system?
If you email me for instance, Google has your email shrug.
Grinich also points out that developers can build using
the Inbox APIs for free, without sending email data to
a third-party.
In the future, however, the company will release a
hosted version of Inbox that will allow developers to
create applications without needing to also scale their
own infrastructure.
... but you can if you want. And if that sounds interesting, maybe you should work with us? :) jobs@inboxapp.com
I work with email currently, and one of the core mantras we have is that nobody should be able to read the email of someone who uses our service. It's such a personal thing with so much private information, that even the possibility of someone being able to do that (especially when there are more than a handful of us) is unpalatable to everyone here, to the point that we can't do common password recovery in order to keep that information private from us. I certainly hope you are/will take that into consideration as you build this.
Sounds wonderful. Where do you work?
IMAP has a lot of shortcomings, but at least it is a standard.
That said, Inbox' approach seems nice in that it wraps a new API around 'legacy' protocols as well.
I actually looked pretty closely at JMAP when it was announce. It's really just a JavaScript wrapper around IMAP conventions. Plus, there's no way to actually use it-- it's just a document spec.
The thing people don't realize about IMAP being a "standard" is that there are tons of extensions, weird bugs, provider-specific edge-cases, no comprehensive tests, no reference implementation, etc. If you mean it has an RFC, then yes it's a standard. But actually working with it is still hellish.
We're trying to fix email from a pragmatic, developer-focused point of view. We just want to build new apps and services without the struggle of old protocols or dealing with character encodings. The philosophical argument can come later when the dust settles.
But I can't see such a thing taking off unless it's Free.
Read an email and then flag it as unread? Save and delete instead of move? Batch operations that are not atomic? What happens when the connection breaks then?
Synchronous command requests, really? IMAP solved that 20 years ago. Do we really want a glorified POP to replace it?
What is the purpose?
"Move" is greatly simplified if "location" is a tag field like gmail rather than anything to do with filesystem storage.
The purpose would be building web apps that manipulate email.
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 would you control whitelisting? Spam scoring? Folder ACLs? How would you sleep until a mailbox changes? Even if you _could_ represent these things as resources, it's going to be much more hairy than IMAP with the performance of POP.
The evolution of email has been completely opposite of dumbing it down. Users expect calendaring and global contact lists, and here you have the impedance mismatch _again_. Look at the mess that is CalDAV, and that's DAV which is much richer then REST.
Regarding asynchronous commands, I don't know what you think it has to do with AJAX. It is the Javascript that is asynchronous in AJAX, not the HTTP requests. Web browsers typically implement it using multiple connections. This is a problem. Do you really want connection pooling (so a server can serve _fewer_ clients)? No, you want an evented protocol. Such as IMAP.
And again, you probably could do it given enough work and come close to the performance of IMAP for most end users, but why would you? It doesn't really map to the REST architecture.
It you would rewrite your comment but s/REST/RPC/ I would not object to it. I would just think you were from the past :).
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).
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.
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).
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 uploaded once, not duplicated and sent over the network
- Better filtering (this one isn't bad currently, but can always be improved)
- Integration with other forms of messaging
- Better support for public messages like mailing lists or mass mailings, e.g. URIs for messages or parts thereof (attachments etc).
- Single signon (get rid of passwords on websites by producing an email replacement so awesome people use it as a central identity)
...etc. There are plenty of possibilities, and the ones at the top of this list I think would benefit a lot of people and make things like spam a lot harder.
I'm not sure this particular service is going to succeed (it reminds me of app.net in that it targets developers, which is probably a bad idea for mass-market tech), but there are plenty of things we could improve about email and email clients.
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 the network
So you're depending on the remote party to AV scan incoming attachments? Seems flawed.
> Better filtering
How? What tech' is in place to make filtering easier/better.
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.
[1] https://www.cs.princeton.edu/~jcnelson/steak-whitepaper.pdf
[2] https://github.com/jcnelson/syndicatemail/blob/master/papers...
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.
I'm willing to bet that they'll have significant problems with the name if they try to call it just "Inbox". First, they didn't even get the inbox.com domain, theirs is inboxapp.com. Second, they don't seem to have a trademark on the product name as "Inbox" and I doubt that they'd get one. Third, their company name is Inbox App, Inc., so it doesn't seem like they did anything special in terms of buying rights or domains.
[1]: http://whois.domaintools.com/inboxapp.com
[2]: https://web.archive.org/web/20110201102718/http://inboxapp.c...
any plans for a WebSocket API? seems like it would be easier to receive pushed emails on an existing socket, than registering a webhook and then sending a push notification out-of-band to the client to fetch new emails.
It's great that Inbox is also built on top of IMAP. The new Gmail API is great, but an application which takes advantage of it is locked into using only Gmail. By building from the standard, Switchboard and Inbox are cross-provider.
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..."
If it is, then what are the "email applications" that require this API? To me, the problems with email are its plain-text nature, spam and managing the vast quantity of mail we get. Does Inbox help 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).
1. IMAP's base spec (RFC 3501 [1]) offloads implementation on the client rather than the server. For example, the client must be able to parse the IMAP protocol, it must have be able to create threads by searching through emails, it needs to implement the logic for syncing, ... etc.
2. There are many IMAP extensions to patch the issues of the original spec [2], but implementation of these extensions across email providers is fragmented, and implementing them both server and client is plenty of work.
This is an attempt at a modern, cohesive API for email.
More seriously, we're super focused on MS Exchange support for enterprises. Ping me if you'd like preview access to this: mg@inboxapp.com
Anything hosted in big shared data centres in the USA cannot be more secure. That's last year's thinking, not "next generation".
Even though I'm probably not you target audience, but I'd love to replace Outlook web client (and Gmail too) with something else.
iOS: https://github.com/inboxapp/inbox-ios
JS/Angular: https://github.com/inboxapp/inbox.js
Full API docs: https://www.inboxapp.com/docs
I've routinely used email like an IM system with folks in different companies. GMail will spool email in <30 seconds. Exchange can be near instantaneous.
One of our goals is to make transit as fast as possible. But there's a limit to what Inbox can do right now since it works on top of existing providers, like Gmail or Yahoo! Mail.
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.
Inbox integrates with your existing email accounts---we connect to the provider via IMAP, and provide a nice REST API on top of that. We don't support POP right now, but there's no reason we couldn't if there is demand.
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.
Not like they can't shutdown their company irrespective of any promises.
Really, I'm more uncomfortable with a link to a webcomic joke as an argument point...
You seriously don't think you called him a fuckwad?
You are just as rude as the activity you're calling out. That's all I'm trying to say.
Whatever it is, it's worthless.
The 'shut up' detracts from the comment. Being a jerk is bad.
But being confrontational is in this case a benefit. The first line is "Your claim that your product will not be discontinued is worthless." This is confrontational in a good way, and this line is not being a jerk. It's pointing out a serious flaw without attacking anyone.
Something like, "How will you back up your claim of the product not being discontinued?" or "What will prevent your product from being discontinued?" Gets the same point across without coming off rude (it may just be me but saying "your claim ... is worthless" seems rude.) The OP of the comment definitely has a good point but it's said in a way that isn't constructive.
They will gladly shut the service down once someone offers them enough money in aqui-hire.
Probably the only convincing thing I can say is that if you wanted to build a company to flip quickly, an email infrastructure startup is certainly the most painful, masochistic way you could go about it. We spent the better part of last year reading RFCs and fixing tons of obscure bugs to get this far.
'unexpectedly' is the key. Giving people 3-6 months of runway to say "we're shutting down on day X" is still living up to that statement.
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 API. I'd love to hear any comments you have on what guaranteed level of support+performance you would need for a hosted product. We're working on a hosted version now (so you don't have to run it yourself), and developer happiness is the #1 priority.
Makes the existing user base much less valuable to possible buyers though :)
And we (gwillen and anyone who agrees with his comment, myself included) are just a few hackers who are tired of having the rug pulled under their feet when $CORP inevitably comes with the big bucks and all claims made by the founders in the early days of the company mysteriously disappear from the homepage.
Talk is cheap.
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
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.
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".
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.
Your comment is needlessly mean-spirited. The top-voted comment on the recent Show HN thread would seem to apply here: https://news.ycombinator.com/item?id=7984826
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.
Take it down a few notches, you're solution will likely not work.
This is the company's only product. If the product gets discontinued, the company is likely broke. The "significant monetary penalties" is unenforceable because the company will not have any money to fulfill the SLA penalty.
Or has just been acquired, which I think is more what the parent was getting at.
>The "significant monetary penalties" is unenforceable because the company will not have any money to fulfill the SLA penalty.
The acquirer would, though!
But I'm so sick of startups just being R&D for corporations and screwing over their userbase once they get acquired. Or even worse is companies that only get off of the ground because of user support via kickstarter or similar fund raising platforms and then get acquired.
Of course it would be much harder for those companies to raise funds but there's always bootstrapping. It'd be a big win for the consumers of the product and if marketed correctly (something like "Non-Acquirable LLC"), it could become a good way for a startup to show that they put their users first.
I was involved in setting one up at university (http://www.srcf.ucam.org/) and it's still running long past the time I had anything to do with it. I believe it's a good model for "community" internet services, by definition run in the interests of the users.
It's not impossible for one to sell out, but it requires the members (customers) to vote for it. In the case of the UK building societies, by bribing them with the capital reserves that were turned out to be essential to keeping the mortgage system running.
You'd hope there'd be a lesson in there somewhere - short term gain versus long term stability.
Having clauses with each investor that let you purchase back your shares from them at predetermined times and rates (returns would need to be healthy for them) limits their upside, but lets you buy back control whenever. - assuming you can afford it
for public companies in the US, also see "Poison pill":
http://en.wikipedia.org/wiki/Shareholder_rights_plan
http://blogs.wsj.com/moneybeat/2014/06/30/dealpolitik-poison...
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 think the comment created worthwhile conversation. And I'm not sure it would be better off without it. Obviously you can disagree, and given your position perhaps my opinion doesn't really matter, but to say it has no information is just being dishonest, and I say that in the nicest way possible.
I see two conversations here. One is about users feeling betrayed by acquisitions and whether that could be mitigated contractually. That conversation didn't require abusiveness to be created. The other conversation is about who is being a fuckwad, and hardly counts as "worthwhile". Unfortunately, it is what such rudeness leads to, and it only gets worse.
Keep in mind that we're not talking about rudeness in general. We're talking about its effect on the already precarious balance of a particular optionally-anonymous internet forum. The argument here isn't ethical so much as empirical.
(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.
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 an ethical injunction so much as a practical tradeoff.
I do not recall before today just looking at a new company's elevator pitch and muttering "Best wishes with the acquihire, y'all". Something subtle's shifted in the way we perceive startups, lately...
But the above is just my observations at my own behavior. I do wish the best for this company!
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).