Identity fields length

[Swader]

Each identity field length is currently limited to 32 bytes, which breaks many long names or emails, and makes using hashes impossible (e.g. ipfs hash for image field, or even custom fields).

A full IPFS hash that also notes protocol and type is 71 bytes (ipfs://ipfs/bafybeib7jqo7haiiruinbsqasv4jwhavm4pwe6fjr6b4fulnrhpe6rz5yi), so 128 makes sense across the board imo. We could split the hash into 4 custom fields and concat them, but this seems like an ugly standard-breaking hack that not many UIs and apps will be able to adopt in a clean way, so we'd rather propose a cleaner approach like raising this limit.

[coriolinus]

What's wrong with just hashing the identity field of your choice with one of BlakeTwo256, Sha256, Keccak256, ShaThree256?

[Swader]

Then I need to store the original value somewhere off chain, which makes cross-app usage impossible unless they all know where to look for this data? Imagine the scenario of adding a "tiktok" custom field. My app hashes the tiktok username and puts it into the field, and another app, like identity directory, wants to display that. How does it find the original username?

[coriolinus]

Or just store the original value alongside the identity value, as pure data.

struct HasTiktokIdentity {
  /// Derived from `self.tiktok`
  identity: Data,
  /// tiktok username
  tiktok: String,
}

[Swader]

Sorry, I'm confused, how do I use this approach on Kusama's identity pallet as-is now? The fields in the identity (including custom fields) are all limited to 32 bytes. I am not interested in adding new runtime logic or extending the identity pallet for a custom chain, I want to alter the data length so that the identity module on Kusama and Polkadot becomes more usable beyond the simple and short values it can store now.

[xlc]

Correct me if I am wrong, but I think you can derive IPFS multihash address with 32 bytes hash if you know the hash algorithm, which enum Data does includes it.

[Swader]

To properly identify the data source, you need the protocol and type too. So even if I could somehow shove an IPFS hash into 32 bytes, I still need room for ipfs://ipfs, otherwise a client has no idea if they should read http://, or ark:// or even ipfs://ipns.

[Swader]

Any further ideas on how to get around this problem without breaking the data into several fields and concatenating them, aside from raising the limit from 32 bytes to something like 128?

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

[Swader]

This is still relevant and currently an app-breaking problem