x/Staking: make validator info have an explicit link to profile pictures

[ValarDragon]

Problem

Historically, validator info was obtained indirectly, via validators having a link to a keybase in their identity field, and then explorers & wallets going to keybase to find their profile picture and displaying that.

This was making a bet on keybase becoming big, which ended up not panning out. (Even at launch, IIRC, getting cosmos validator profile pictures ended up being a large load on keybase servers)

Now explorers like mintscan maintain their own repository for storing profile pictures, that has no authentication to ensure it maps to what the on-chain validator wanted.

Proposal

We should make validator info field have an explicit field for profile_picture, which links to a png or jpg image of some max size, that explorers / wallets / etc. can all use in a unified manner.

We shouldn't be having images done indirectly via keybase imo, because the scale of cosmos >> the scale of keybase, and clearly this has failed at getting sufficient adoption.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alexanderbez]

I'm not sure if I'd so far as to say that Keybase failed. I'd also be seriously shocked that explorers or clients actually overwhelm their servers.

That being said, I do think it's a bit weird that identity implicitly implies a reliance on Keybase. I don't really feel comfortable about adding profile_picture. Instead, what do you think about modifying the existing identity field to conform to a (TBD) format. E.g. <type>:<URI>.

e.g.

• png:https://gravatar.com/avatar.png
• keybase:B20C...

type can be completely open or we can limit to a supported set (png, jpg, keybase, etc..)

[ValarDragon]

The explorer / client overhead was AFAIU an issue in like the first month of launch, though I could be totally wrong!

Hrm, why is profie_picture weird though. Basically everywhere people have public identities have profile pictures. I feel like it simplifies supporting profile pictures, since otherwise we have one of the following two situations:

1. folks would need to implement getting profile pictures from many different providers
2. or we make identity a list of <type>:<URI> objects, with one of them commonly being png:... / JPG:...

[alexanderbez]

It just seems too limited. Like having <type>:<URI> seems way more flexible to me. We can support direct links, Keybase, Gravatar, etc...

[ValarDragon]

Wait but keybase rn is specifically a profile, not just a link to the image.

I think identity and profile_picture are distinct roles. (identity could be a twitter profile, versus profile picture is just the png everyone PRs to every single explorer / wallet)

[tac0turtle]

Adding a link to a profile picture makes sense. Having something resolve to only the png, jpeg or other format seems fine. From a front end perspective it could be weird with handling different sizes. TBH id prefer to move away from key base to something like the twitter api as an identity. Most people don't use key base and have to set one up for running validators.

[tac0turtle]

what about adding a metadata field that can be extended if needed on the fly instead of needing to update a struct each time.

[PikachuEXE]

I imagine there would be more than one "identity" too
Though there can be some rules/checks for known types to prevent accidental invalid values, I think unknown types should be allowed too
And it's data reader's responsibility & right to choose what types to support

e.g.
identity: twitter:@Something,stargaze_name:plottablegoldentrain,icns:who.cosmos (Not sure what would be a good separator though. ,/;/|?

I am not so sure if profile picture should be fit into identity though. Current implementation seems to be just a side effect due to keybase profiles having one profile picture. Probably not every type of "profile" (known or unknown) support having a profile picture. But I am fine with just adding types for profile picture(ssss) if it's supported (by data readers).