Allow more Third Parties to be "Set"

I did a few searches and didn't find an issue that was quite the same - apologies if I missed it somewhere.

----

The problem I find myself facing, roughly speaking, is that when I trade information with people, I hand out multiple pointers to myself (email, keybase, etc.) because I'm not sure what their preferred method of reaching out to me is. I'd love to be able to hand out *just* my keybase handle, from which my counterparty could pick out whichever pointer makes the most sense.

Keybase has support for a number of these pointers for the purpose of *mutual proof*, but there are a variety of such pointers that do not have an (obvious) mechanism for mutual proof, and are un/under-supported as a result. Examples:

- email address
- venmo/squarecash/etc. handles

The reason I use "Set" in the issue title is that I think the Bitcoin and ZCash integrations actually fall into this bucket of pointers: https://keybase.io/blog/keybase-and-zcash

Basically, it seems like there's a difference between services that provide mutual verification and trust bootstrapping, and other pointers where it's taken as a given that the keybase profile is already trusted and you instead want signed pointers. The latter use case feels under-supported right now, and it feels like it could potentially increase the utility of keybase quite a bit.

I've seen this in a few issues around support for email addresses or SSH keys (https://github.com/keybase/keybase-issues/issues/710), and I'll just make the case here that a) mutual proof *is* needed, but only for a core set of services sufficient to bootstrap trust, and that there are many useful pointers that don't need *mutual* verification (as long as the UI can make the distinction clear - and perhaps this is why it isn't supported), and b) given that you don't have to *mutually* verify, it seems like you could support a fairly broad set of these without going as far as (https://github.com/keybase/keybase-issues/issues/2947).

----

Final thoughts:

- I could totally just stick a file in my KBFS public folder, and honestly, I would personally be pretty happy with an implementation that was "make a yaml file called .kbconfig and add servicename/value pairs" (though perhaps that's not accessible enough for a broad audience). The key difference being that it'd be nice for those servicename/value pairs to show up on https://keybase.io/justinyan (or in the profile in the app)
- If I want it to show up so bad on the profile page, I could add it to my bio - but it's not totally clear to me if that data is actually signed in any way, and it'd be missing the opportunity for that data to be structured and linked (ala the ZCash and Bitcoin integrations) - which would potentially open up opportunities for programmatic applications of that metadata.

Appreciate you taking the time to read - love the product and keep it up!

Start by reviewing the existing Bitcoin and ZCash integrations, then compare how pointers are represented on the keybase.io profile and in the app. Consider the proposed .kbconfig YAML approach and the distinction between mutual proofs and signed pointers; done would mean supported third-party pointers appear as structured, clearly labeled profile data.

Written by the indexing model from the issue text.