pallet-identity: Make identity generic

[bkchr]

IdentityInfo is currently declared in pallet-identity:
https://github.com/paritytech/substrate/blob/f6928f87138c25e0f16821a19fb1feb0edf8e214/frame/identity/src/types.rs#L290-L334

It already supports additional identities that are free for the user to choose. However, people are still opening issues about wanting special fields for discord, github or whatever to be added. It would be much better to make the whole IdentityInfo generic via the Config trait.

So, a IdentityInfo associated type should be added to the Config trait and everywhere where currently IdentityInfo is being used, should be replaced by T::IdentityInfo. To stay backwards compatible, we should keep the old IdentityInfo struct and then all downstream users can just point the Config::IdentityInfo to pallet_identity::IdentityInfo.

[hirschenberger]

I'd like to do this.

[ggwpez]

Yes its a good issue, thanks @hirschenberger.
It is quite involved and will probably require migrations on Polkadot. So maybe first prototype it on both sides (Substrate+Polkadot) to see that your design works.

cc @chevdor see what we are doing here? Networks can have more variety on what Registrars can judge on, and the format will change.

[chevdor]

Thanks for the heads up @ggwpez, that will likely break a lot on my end but that is not a concern :)

This additionnal field it not really useful as each user add their own custom Discord, Discord , discord and dicsord extra fields and let registrars deal with it if a judegement is requested.

It is good if a chain can define what an Identity is so they also can decide to have a Riot field or not :)

It would be also great to consider that a chain may want to have multiple type of Identities. A chain may want a simple base Identity for all but a version with more information for some populations. That can be handled with more Optional fields and enforced by registrars but leaving this decision to the chain authors make it more elegant.

[bkchr]

It is quite involved and will probably require migrations on Polkadot. So maybe first prototype it on both sides (Substrate+Polkadot) to see that your design works.

This shouldn't be really involved? You only need to move the identity to the config trait. You also don't need any migration if you just continue to use the current identity struct.

[bkchr]

It would be also great to consider that a chain may want to have multiple type of Identities. A chain may want a simple base Identity for all but a version with more information for some populations. That can be handled with more Optional fields and enforced by registrars but leaving this decision to the chain authors make it more elegant.

We should probably make it possible for registrars to specify for which fields they can attest. Then the registrar is always attesting for the same fields of all the identities they approve.

[chevdor]

@bkchr that would totally make sense and would be a helpful addition if the info is available on chain.