Former Keybase employee here: Keybase has pivoted quite a bit, but I'd suggest it still matches your description: a repository of public keys tied to/verified v

Former Keybase employee here: Keybase has pivoted quite a bit, but I'd suggest it still matches your description: a repository of public keys tied to/verified via social media accounts, with infrastructure to facilitate their use. The type of the keys has changed; NaCl Ed25519 keys are now heavily emphasized over PGP keys. And the infrastructure has grown to include both the proof framework beneath the keys, and user-facing applications built on top of the keys. I think one of the big takeaways from the legacy of PGP, is that a public key system in isolation won't be a successful base for mainstream applications. Some thoughts on that from the Keybase perspective: 1. Public key models are difficult to understand. Asking users to learn what a key is, and then to manage the way their keys interact with multiple different services, is too much in practice. (Both in terms of adoption, and in terms of avoiding security mistakes.) 2. Public key models are difficult to design. The Keybase model is very different from the PGP model, for example in that it avoids relying on any single "master key". That's a better fit for users who tend to have many devices but who tend not to have a great personal backup strategy. This is the sort of thing that made sense by 2013, but didn't make sense in 1991. 3. After you design a key system you still need to iterate. Keybase added a concept of Per-User Keys (shared by all devices, transported using device keys) while chat was being designed, because it was a better fit for the security model that chat needed. If Keybase wasn't in control of the key model and the chat application at the same time, making that change would've been impractical. There have been many other changes like it -- exploding messages using ephemeral keys, for example -- and I'm sure there will be more to come.