Concernant le UserID, ce qui m’en semble essentiel c’est qu’il soit modifiable.
Partons des usages comme le fait @kimamila, on décidera dans un 2ème temps si on le stocke onchain ou offchain (ou onblock).
Concernant les usages, j’assume que:
- Je dois voir le pseudo de la personne que je certifie.
- Le pseudo doit être modifiable à long-terme (ça me semble acceptable qu’il ne soit pas modifiable avant la validation complète de l’identité).
- Si le pseudo a été modifié il y a moins de X jours, je dois avoir une alerte dans l’UX, et lorsque j’appuie sur cette alerte, ça doit n’indiquer que le pseudo a changé récemment, et m’indiquer quel était l’ancien pseudo).
Concernant le choix du stockage onchain ou offchain, il y a en réalité un 3 ème choix, ou plus précisément, le terme onchain n’est pas assez précis, et peut désigner 2 réalités différentes:
Il faut dissocier le contenu des blocs d’une part, et le storage onchain d’autre part. Le storage onchain est la seule partie qui doit nécessairement être conservée par tous les nœuds du réseau, et qu’il convient de garder légère sous peine d’impact négatif sur les performances et la scalabilité.
Concernant les blocs, le seul impératif est de conserver les blocs non-finalisés, soit en moyenne 5 à 10 blocs grand maximum!
Les blocs plus anciens ne sont conservés que par les nœuds d’archive, les nœuds d’archive ne servant qu à déployer de nouveaux indexers, ou restaurer des indexers down depuis longtemps ou avec une corruption de donnée.
Les nœuds d’archive peuvent être peu nombreux, n’ont pas besoin d’écrire des blocs, et peuvent donc sans problème être réservé à des machines avec beaucoup de stockage.
Ce que je veux dire, c’est qu’entre un stockage onblock et un stockage offchain, dans les 2 cas la donnée devra être stockée quelque part sur quelques machines, donc ça ne change rien en termes de taille de stockage.
Pour stocker une donnée onblock mais pas onchain, rien de plus simple, il suffit de créer un paramètre inutilisé dans un extrinsic.
En revanche, le storage onblock reste une violation du droit à l’oubli, mais dans la pratique, même avec un storage offchain, difficile d’être sûr que toute trace est effacée, une vielle copie peut toujours persister quelque part.
Bref, tout ça pour dire que je suis ok pour que le UserID soit stocké onblock, cela permettrait de le rendre accessible par l’api graphql de Hydra par exemple 
Je propose donc:
- D’ajouter un paramètre inutilisé
idty_nameà l’extrinsiccreate_identity - D’ajouter un extrinsic
change_idty_namequi vérifie que l’appelant une identité validée (membre de la wot) avec paramètreidty_nameégalement inutilisé afin de ne pas alourdir le storage.
Un système d’historisation tel que Hydra devrait alors être capable de fournir l’historique de tout les pseudos d’un membre et leur date de modification.
Il reste la question des comptes simple portefeuille, on pourrait y rattacher un « membre propriétaire », afin de pouvoir appliquer un quota.
Plus généralement, toute donnée à stocker doit être limitée soit par des quotas soit par des frais. Dans le premier cas cela implique que toute donnée soit rattachée à un propriétaire identifiable, dans le 2ème cas cela implique que l’utilisateur doit avoir suffisamment de Ğ1 pour créer ou modifier son profil.
On peut également mixer les deux: donner la possibilité de rattacher optionnellement un propriétaire, et ne faire payer que si aucun propriétaire n’est rattaché.