J’ai retrouvé le sujet en question :
et ce post en particulier :
1 Like
OK, je n’avais pas vu passer ce post.
Pour répondre rapidement : non, en effet, l’UID n’a aucun intérêt technique. Mais il a un intérêt humain pour construire la WoT : poser un identifiant « qui parle » et qui constitue un point d’appui solide permettant de sécuriser la certification (et donc la WoT, et donc la monnaie).
C’est pour ça que je ne souhaite pas qu’il soit off-chain. Par contre, selon moi tout le reste peut l’être : nom, prénom, etc.
Autre argument mais plus faible : nous ne sommes pas à l’abri de changer de système cryptographique, dans ce cas l’UID pourra servir d’invariant.
5 Likes
On sort du sujet, donc je renvoi à cette discution:
De toute façon on en est pas à réfléchir à changer le protocole, juste à l’adapter pour le rendre optimal pour Substrate il me semble.
1 Like
Le sujet est de savoir si le pseudo doit être connu des le démarrage du processus d’adhésion comme membre.
Si
- seule la clef publique est nécessaire pour stocker la première certification (on-chain), comme le suggère @cgeek,
- et que le pseudo peut être renseigné plus tard par le propriétaire du compte, lors de l’émission de son adhésion
Alors cela signifie que le pseudo ne sert pas aux certifieurs, qui ne peuvent s’appuyer dessus pour vérifier que cette personne n’aura qu’un seul compte membre.
Il leur faut donc retenir la clef publique, pour suivre ensuite l’évolution de ce compte, et non plus seulement le pseudo. Ceci me semble faciliter les fraudes, ET rendre plus complexe la vérification par les certifieurs. En gros le pseudo ne sert plus pour le contrôle (par les membres) de la WoT…
Prenons un exemple :
- j’envoie ma clef a des membres pour qu’ils me certifient. A aucun moment ils ne connaissent le pseudo que je vais utiliser ensuite.
- j’obtiens mes 5 certifications et décide, sans avoir besoin de leur dire, le pseudo ‹ DonaldTrump ›
- je les recontacte quelques mois plus tard pour un paiement
- plutôt que de redonner mon pseudo precedent, je donne celui d’un autre compte que j’ai créé de la même façon, avec 5 autres personnes : ‹ BenoitLavenier ›.
A quel moment vont ils faire le lien, que j’ai en réalité deux comptes ? Quel outil auront ils pour être aider dans leur rôle de vérificateur ?
S’ils consultent leur historique de certification, il verront Donald Trump, mais sans pouvoir dire qui leur avait fait cette demande…
Voyez vous ce que je veux dire ?
Bises
Une solution alternative, est de pouvoir certifier une clef publique associée à un pseudo.
Un peu comme le fait d’inclure systématiquement le checksum (par exemple dans le format standard des copier/coller de clefs), on pourrait avoir un format du type : <clef_publique>::
Voir mieux : un checksum après le UserID pour être certain d’avoir tout copier/collé :
<clef_publique>:::
Le pseudo n’étant nécessaire, dans ce cas, que lors de la toute premiere certification. Dans les cas suivant, même si le copier/coller est mal fait, le UI pourront le détecter et afficher le bon pseudo au certifieur avant qu’il ne valide sa certification.
1 Like
Oui ça c’est pas mal, que la certification inclut nécessairement le pseudonyme associé.
Et que lors de la publication de l’identité, toute certification qui ne respecterait pas ce pseudonyme serait alors détruite et devrait être rejouée (sans délai de rejeu, si ce n’est le délai de 5j anti-spam).
Oui 
Personnellement je serais favorable à une simplification :
- Il est possible de certifier un compte porte-feuille
- Si un compte portefeuille à 5 certifications ou plus, ce compte hérite du droit de produire le DU, de certifier, et d’écrire en blockchain (si on reste sur le couplage de ces 3 droits)
C’est tout.
Le document d’identité pour moi n’a pas besoin d’être en blockchain.
On peut très bien avoir un identifiant géré par cesium+ ou autre système externe et que la blockhain se contente de clef publique.
Les certifications ne pouvant être émise que par des comptes certifiés, les quotas peuvent s’appliquer.
La licence est la pour réguler la manière de certifier.
Ça me semble suffisant.
EDIT :
En fait, si on veux s’assurer que le titulaire du compte est vivant, effectivement un document d’identité semble utile pour l’expliciter chaque année. Ceci dit, une règle qui désactive les droits lié aux certifications pour un compte qui n’a émi aucun document depuis 1 an fait aussi l’affaire (et dès lors que le compte est actif à certifier ou émettre des transactions, c’est que le titulaire à accès à son compte, donc ça peut faire le job sans rajouter de document spécifique, mais en ajoutant une règle de gestion.
2 Likes
C’est la solution que j’aimerais retenir, qui va dans le sens de la dernière proposition de kimamila.
Oui, la blockchain n’en a pas besoin. Mais comme dit plus haut, le pseudo est là pour faire le pont entre la technique et l’humain, à travers une donnée fiable (ce qui ne serait pas le cas en off-chain).
Je crains qu’en enlevant le pseudo :
- on augmente le risque d’erreurs/fraudes (avis de @kimamila également) car celui-ci agit comme un CRC humainement très lisible (un pseudo est choisi pour être prononcé par les pairs)
- on déshumanise le processus, car en ayant le pseudo obligatoire celui-ci se retrouve aussi dans la mémoire des utilisateurs, tandis qu’une clé publique y est très vite effacée. A y repenser, c’est peut-être ce que je crains le plus, car faut-il le rappeler : toute la Ğ1 repose sur l’humain. Ce dernier doit y être impliqué sans quoi l’effondrement n’est pas loin.
C’est le rôle du document d’adhésion, qui ne contient pas de pseudo. Et qui sert aussi de déclencheur à la vérification de la distance (calcul très coûteux). L’identité n’est pas utile pour ce cas.
4 Likes
Je comprends les points positifs du pseudo, mais il a un gros point négatif :
- c’est un champ libre comme le champ commentaire.
Il a donc les mêmes problèmes que le champ commentaire.
Il nécessite donc une validation de la donnée pour éviter des attaques par injection de code. Et aussi par des attaques sociales (mots racistes, insultes, usurpation d’identité par homonymie ou autres). C’est le côté attaque par l’humain.
Je pose ça là pour bien sécuriser ce champ.
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é.
Je parlais bien de le mettre dans le Storage, afin de ne pas autoriser les doublons.
Autoriser la modification, pourquoi pas, mais bon ça ne me semble pas prioritaire du tout.
3 Likes
J’espère que cela n’empêchera pas d’avoir des comptes anonymes. Juste pour être sûr.
3 Likes
Je fais revivre ce débat suite au dernier ticket de @tuxmain #118.
Mon avis est le suivant :
- si on a un userid en blockchain sur lequel on base toutes les UI, alors il doit être définitif et immuable
- si on veut plus de souplesse sur un pseudo associé à un compte membre alors il vaut mieux l’avoir hors chaîne principale et revoir les outils pour ne plus considérer le pseudo comme immuable
J’aimerais attirer l’attention sur le fait que Duniter v2 :
- permet déjà le changement de clé (change owner key), la clé n’est donc plus l’identifiant de l’identité
- a comme seul identifiant immuable le identity index
- considère le pseudo uniquement comme un élément déclaratif ; sa déclaration a lieu après la première certification et conditionne la réception d’autres certifications
Ce que je préconise :
- on change le minimum par rapport à la v1 donc on garde un userid immuable
- on change le minimum de chose dans le code v2 existant, donc on garde un userid déclaratif
- on peut éventuellement ajouter des index dans le storage pour obtenir l’équivalence idtyindex
userid sans passer par un indexeur - si jamais on veut revoir ça, il faut le faire après la migration et avec l’avis de la communauté
J’aimerais qu’on se mette tous d’accord sur ce sujet parce que mine de rien c’est assez structurant.
4 Likes
Je suis d’accord avec tout ça.
2 Likes
Je ne vois pas bien pourquoi ces deux solutions seraient exclusives.
Oui voilà, restons simples pour l’instant et sortons cette Ğ1v2.
3 Likes
Je reviens un peu sur ce sujet, il y a un point qui n’est pas couvert par le message d’Eloïs ci-dessus : le Genesis.
Actuellement, sauf pour les indexeurs qui bénéficient d’un fichier à part où le lien pseudo ↔ identité est explicite, il n’y a pas moyen de connaître juste via le Storage le lien entre un pseudo et une identité. 
Le stockage onchain actuel ne fait que lister les pseudos déjà réservés.
C’est un peu pénible, surtout que l’on parle quand même d’un volume de données assez faible.
Avant de lancer la ĞDev 600, est-ce qu’on ne reverrait pas ce point ? cc @HugoTrentesaux et @tuxmain notamment pour votre avis technique.
1 Like
C’est une des raisons pour lesquelles j’avais changé le format du genesis pour rendre explicite la correspondance pseudo ↔ idty index :
"poka": {
"index": 61, # <---- ici
"owner_key": "5CQ8T4qpbYJq7uVsxGPQ5q2df7x3Wa4aRY6HUWMBYjfLZhnn",
"balance": 1113895,
"membership_expire_on": 2010532,
"next_cert_issuable_on": 0,
"certs_received": {
Par contre, à moins d’avoir le genesis en json ou un indexeur qui a eu le genesis, il n’y a pas moyen de récupérer la correspondance en blockchain.
On pourrait a minima remplacer le set IdentitiesNames par une map {pseudo → idty_index} et se contenter d’un indexeur pour avoir le sens inverse. Est-ce que ça répondrait à la problématique ?
Je me sens d’ailleurs un peu bête de ne pas l’avoir fait avant, on a des clés en Blake2_128Concat qui font 464 bits (128 + 42×8), et pas de valeur, alors que un idty_index serait uniquement 32 bits.
Oui ce serait suffisant.
Le Concat vient de moi, avant c’était juste 128bits.
Ceci dit, je reste convaincu que 32 bits (ou 32 + 42x8 = 368 bits max) reste peu de choses par rapport aux volumes de comptes et de certifications.
J’ai directement commité sur ma branche : fix(#125): feat(identity): associate idty_index to uid (961e69c3) · Commits · nodes / rust / Duniter v2S · GitLab
1 Like