A good article that covers what Keybase is, where they came from, what they try to do, and where they're trying to go -- although you couldn't tell from the headline. As in the article body, Slack is namedropped just for effect; Keybase Teams being a decent proof-of-concept of a popular kind of application to show that the ideas behind Keybase can be used to build real products. That being said, Keybase has been movi…
We really thought we'd stick up the Keybase directory, make some basic scripts, and move on.
Upon further review and growing popularity, we realized we'd hit a nerve but only solved one of 3 problems related to public key infrastructure.
(1) the identity problem; this means think of a PERSON, and end up with a key. This really is what started Keybase. It was made possible because of how identity has changed in recent years. Whether you're following a famous developer or you're looking up your own sibling, odds are in 2017 you know a public definition of them: a Twitter account, Reddit account, Facebook, etc.
When attacking point 1, we made it a lot more than just posting a fingerprint. We needed these proofs to be bidirectional. It's not just that you should be able to start with a Twitter account and get a key; you should be able to start with a signed statement and end up on the Twitter account. We also attacked revocation and other issues.
But really, there were 2 big missing pieces:
(2) multi-device key management; the OLD shitty story was having one private key that you moved around from device to device. This was never an acceptable solution for most people. What the heck is a private key? How do I move it around? What if just one of my devices is compromised? And so on.
In 2015 when we decided to commit to Keybase, smartphones were poised to solve this. They solved this by guaranteeing that whatever 2 devices you have, you can always bring them together. So you should never have to move a private key around again. In the mobile era, you can bring 2 devices together and declare they're both you. Technically, underneath the surface, device #2 generates its own key pair, and device 1 signs the new public key, and device 2 countersigns this, and all this goes into an immutable chain (by signing the hash of the last identity change).
This means you don't need to understand what a key pair even is. It feels roughly the same as when your bank tells you to grab your phone in order to log in.
And if you have a compromised device, your identity isn't destroyed.
This was the 2nd thing we wanted to tackle.
Finally, to address your point, number 3.
(3) all the GUIs around PKI really kind of sucked. There were some standalone chat apps that were good, but nothing that got people building a real graph of keys and identities, so they can do whatever else they wanted. For a PKI to work, people needed usable software on every platform. And it couldn't be constrained to people in your phone book, where you needed to securely exchange a phone number first.
We think the basics of a usable PKI are:
(1) to know who you're talking to (and to trust teams)
(2) to be able to share data, securely, on any platform
We really felt that only by solving all 3 problems would a general PKI ever take off.