The simple idea is that it's a directory mapping public keys to social accounts. If I know you as a Twitter user, I might want to send you an encrypted message. Or if I get a message from you that's signed, I might want to know that you're a certain Hacker News user. If I download some source code, I'd like to know it was signed by someone who has Github account X, and write access on example.com. And so on.
Historically, a few people using PGP would do this identity mapping, at least in one direction, by posting a PGP fingerprint (of their public key) on their, say, Twitter profile . Of course, this only went in one direction. To achieve a bidirectional proof, they would also have to post a signed statement going in the other direction, too, stating they were in fact that twitter user. (Otherwise you couldn't start with a message and conclude which Twitter user sent it - multiple people could claim this.)
Keybase started as a hobby project to make these posts structured and formal for PGP users. We just wanted to make this kind of thing easier, so we made a directory to hold the signatures going in the other direction, and a reference client that would look up these announcements and verify them.
The other specific advancement is that these signatures have been put into a data structure designed to prevent the server from lying by omission or forking - a big problem that exists with historic key servers. If you remove a key, what's preventing the server from not admitting that? Or what's preventing the server from giving Alice and Bob a difference experience from Charlie and Diane?
Anyway, that was the first idea behind Keybase. To make a better directory and walk people through these proofs.
What we realized - and what has gotten us both (a) extremely smart developers to join us, and (b) funding - is that there are deeper problems beyond the identity establishment....problems that can be solved in 2015.
Those two problems are (1) pretty sucky clients for public key crypto (at least from the perspective of non-programmers), and (2) key management issues. The first is something we have experience with, as our team has worked on a lot of successful projects. And let's be clear, lots of teams could solve this, if given the resources. The second is something we feel can finally be solved thanks to mobile phones. Phones and watches and other small devices allow you to provision new keys easily, because 2 devices can be brought together. That wasn't easy in the past. All this is now possible without understanding what a key is. Or worrying about how to store and move one around safely. That's the new goal: actual crypto clients. For signing, verifying, encrypting, decrypting, and sharing.
You can read the front page of keybase.io for some more info, but it's somewhat out of date and talks mostly about PGP. This will change when our clients are further along and we're seeking more beta testers.
The tl;dr: Removal statements are signed into a chain of all public announcements you make (each references the last), and each link also references the root of the site's merkle tree - a tree which includes everyone's chain. The root of that tree is written to the bitcoin blockchain multiple times per day.
Historically, a few people using PGP would do this identity mapping, at least in one direction, by posting a PGP fingerprint (of their public key) on their, say, Twitter profile . Of course, this only went in one direction. To achieve a bidirectional proof, they would also have to post a signed statement going in the other direction, too, stating they were in fact that twitter user. (Otherwise you couldn't start with a message and conclude which Twitter user sent it - multiple people could claim this.)
Keybase started as a hobby project to make these posts structured and formal for PGP users. We just wanted to make this kind of thing easier, so we made a directory to hold the signatures going in the other direction, and a reference client that would look up these announcements and verify them.
The other specific advancement is that these signatures have been put into a data structure designed to prevent the server from lying by omission or forking - a big problem that exists with historic key servers. If you remove a key, what's preventing the server from not admitting that? Or what's preventing the server from giving Alice and Bob a difference experience from Charlie and Diane?
Anyway, that was the first idea behind Keybase. To make a better directory and walk people through these proofs.
What we realized - and what has gotten us both (a) extremely smart developers to join us, and (b) funding - is that there are deeper problems beyond the identity establishment....problems that can be solved in 2015.
Those two problems are (1) pretty sucky clients for public key crypto (at least from the perspective of non-programmers), and (2) key management issues. The first is something we have experience with, as our team has worked on a lot of successful projects. And let's be clear, lots of teams could solve this, if given the resources. The second is something we feel can finally be solved thanks to mobile phones. Phones and watches and other small devices allow you to provision new keys easily, because 2 devices can be brought together. That wasn't easy in the past. All this is now possible without understanding what a key is. Or worrying about how to store and move one around safely. That's the new goal: actual crypto clients. For signing, verifying, encrypting, decrypting, and sharing.
You can read the front page of keybase.io for some more info, but it's somewhat out of date and talks mostly about PGP. This will change when our clients are further along and we're seeking more beta testers.