Feature Clarification/Requests: Identities, Key structure/metadata, and other dreams.

Preface: Keybase, AWESOME idea. I think I may have a bit of a misconception/wrongfully developed preconceived notions... on what keybase is though. I will get into that in detail at the bottom, but first, let me outline the features that I'd like to see (in an effort to avoid TLDR).

I'd like to see the ability to do a few things:

1) Modify key structure and items associated. The metadata of a key. Keys are able to have multiple user IDs. In GPG, this is actived by "gpg --edit-key ; adduid". This form of additional trust/proof is what also enables the use of different email addresses, and so on. I consider this to be extremely important, and its a feature of GPG that seems to be frequently forgotten/missed.

2) Store more than one key. While the uid feature is great, I have keys for specific use cases that require different security (a much more complex passphrase, for example).

3) If possibe, the abilty to add keybase.io as a queryable key store for GPG keyrings.

4) Custom proofs. Perhaps this could be in the API, the ability to design additional connectors/implement additional proofing mechanisms. There are innumerable services out there, some of which are starting to get the hint and implementing crypto supports, linking keybase and its key information would make this an even easier system for layman users too. Twitter & Github obviously isn't the only goal in the long run, and I expect that this is already something in the works.. just not available due to the alpha status.

5) Generating a private key at start/signup, and properly informing the user that this private key is used to make your information privately yours, not keybase' or others. Or, educating the users to this effect. That would seem pretty valuable to me. If keybase is meant for the user that doesn't quite understand that aspect, of course.

-- Secondary question to this, is our information encrypted with the private key on file? In other words, when the private key was generated, and a passphrase given, is the information (however private) that is stored, encrypted with that private key? In other words, is the chicken that came from the egg, encrypted by the egg?! Or the egg ecnrypted from the... oh you get the picture.
#

Story time. So, when I first heard about keybase.io, I developed this sense that it was going to be a unique, newbie & expert alike accessible keystore with added interfacing for identity provisions. When I logged in and attempted to add my own keys, I was deterred by the single key allowance. I suppose I had a grand vision of keybase being a way for me to finally say that distributing keys is a simple and easy manner that can be done using the GPG search and pull tools!

Ultimatley I've always been a little annoyed at the... seemingly discombobulated key distribution methods that ultimately make the grandiose plans for GPG/PGP type things a little massive in scope. A simple site that makes those things generally forward and easy to do for everyone, while also giving an intuitive identity confirming location that can be used to also apply the same signing/verifying abilities to posts and conversations...

So yea, thats where I'm at. I'd love to see a keyring type feature in Keybase. Obviously if we're talking really good security its smart to not store the real special private keys online where they could potentially get nabbed, but I also think that there are ways to creatively secure that side as well. Encrypting all of the information with the very private key that you generate at signup is a pretty good start I think.

Alrighty, I think I've gone a little overboard. I love the service and the idea already. Want more!

The issue contains several independent requests—key metadata and multiple keys, GPG key-store integration, custom proofs, and key-generation education—without naming files, entry points, or tests. Start by confirming which request is in scope and locating the relevant key, proof, or signup components; done would require an agreed scope, implementation plan, and corresponding tests.

Written by the indexing model from the issue text.