TL;DR
Restons minimaux et fonctionnels on-chain, appliquons des limites anti-spam strictes, facilitons l’ajout de fonctionnalités off-chain et travaillons sur les clients.
Je ne comprends pas tellement l’objet de la discussion sur la publication d’identité. Voici la manière dont je comprends les choses :
- n’importe quelle personne peut générer une paire de clé cryptographiques
lui permettant de chiffrer / signer des documents, et peut stocker ces clés comme elle le souhaite pour utilisation ultérieure sur une autre machine - un compte
devient membre s’il remplit les conditions suivantes :
- il existe un document signé par disant que représente une personne physique unique qui souhaite que le compte A devienne membre (ça correspond aujourd’hui au document d’adhésion)
- il existe cinq documents signés par
, 
, 
, 
, 
déjà membres disant qu’ils connaissent une personne physique capable de signer avec , et qu’ils pensent que cette personne respecte la licence (elle est seule à avoir accès à cette clé, elle ne va pas tenter de créer d’autres clés membres…) - d’autres conditions sur les propriétés du graphe (distance aux “référents”…)
- d’autres conditions sur les dates des documents (intervalle de validation de certification, durée de certification, durée d’adhésion)
- il existe un document signé par
D’autre part, la blockchain principale et le seul moyen d’obtenir le consensus sur le réseau, c’est une ressource précieuse sur laquelle on ne veut stocker que le strict minimum, tout le reste doit passer par d’autres canaux (messages off-chain, stockage off-chain). On ne fait confiance qu’à des membres de la wot pour écrire dedans, et on impose des règles d’acceptation des blocs pour tenter d’écrire le strict minimum.
- il existe un nombre “limité” d’identités membres (par exemple < 1 million)
- on peut donc appliquer des restrictions sur la fréquence d’émission de documents
- il existe un nombre “illimité” de clés valides (par exemple > 1000 milliards)
- une restriction sur la fréquence d’émission de documents n’empêche pas d’émettre un document à partir d’une autre clé, il faut donc un autre mécanisme de limite
Voilà la manière dont je perçois les usages actuels :
- lorsque quelqu’un veut rejoindre la monnaie libre (il ne sait pas encore distinguer membre / portefeuille, il n’a pas encore lu la licence, mais il sait qu’il a envie de participer), il se “connecte” à Césium (traduction = il installe un client), il crée un compte (traduction = il génère un paire de ), il complète son profil (traduction = il publie des infos sur un stockage off-chain comme Cesium+). Ici rien ne doit être écrit on-chain, d’ailleurs je pense que la “création de compte membre” sur Césium (traduction = avec publication immédiate d’un document d’adhésion) est une erreur à éviter.
- quand cette personne participe à des apéros monnaie libre, comprend mieux les règles, et trouve un premier certificateur potentiel, elle lui communique sa publique d’une des manières suivantes
- elle lui envoie directement par mail / sms / Qr-code césium
- elle lui dit de chercher son nom dans l’annuaire Césium+ (donc potentiellement un outil complètement off-chain) et vérifie avec lui que la clé publique correspondante correspond bien en regardant les premiers caractères (ici on peut avoir la discussion sur le format court de clé…)
- à ce stade, le certificateur peut chercher à vérifier que la personne a vraiment le contrôle de cette clé, par exemple en faisant un échange d’une june. C’est une bonne idée, mais on pourrait tout à fait faire cette vérification sans passer par une transaction (écriture en blockchain). Un simple message off-chain signé ferait l’affaire.
- les autres certificateurs peuvent voir les certifications reçues par la personne directement sur la blockchain
Finalement, voilà comment j’envisage le protocole blockchain pour la wot :
- une clé membre a une limite “antispam” d’émission de documents (par exemple nombre de bloc minimal entre deux émissions successives, et/ou un stock dans une certaine fenêtre de blocs),
- une clé ayant reçu une certification gagne le droit d’émettre au maximum deux documents : une “adhésion / création d’identité / association de pseudo (si on veut le garder)” et une “révocation”
- une clé devient membre (écriture en blockchain du changement de statut) quand :
- elle a émis une “adhésion”
- elle a reçu cinq certifications
- les documents précédents vérifient leur durée de validité
- les certifications vérifient l’intervalle “antisybil” de leur émetteur
Je distingue donc le mécanisme “antispam” destiné à protéger la blockchain contre de trop nombreux documents et le mécanisme “antisybil” destiné à ralentir la progression d’une région sybil de la wot. Je ne précise volontairement pas l’algorithme qui choisit laquelle de deux identités certifiées par un même émetteur doit devenir membre en premier, puisque deux nœuds peuvent avoir des règles différentes tant que le résultat vérifie les contraintes de validation.
Section “réponse”
C’est déjà à peu près ce qui se passe aujourd’hui, on peut même ajouter “sur papier” et “à l’oral” à la liste.
C’est plutôt de savoir si on peut avoir cette info en blockchain. Qu’est-ce qui m’empêche de faire un script qui génère des clés et publie en blockchain un document leur affectant un pseudo ?
- soit le prérequis d’avoir une certification sur cette clé
- soit un coût en monnaie
Je suis plutôt pour l’option 1.
Plusieurs solutions, mais je les trouve toutes excessivement compliquées :
- on distingue l’invitation à déclarer un pseudo de la certification, une seule invitation à déclarer un pseudo est nécessaire pour déclarer un pseudo, on ne peut certifier qu’une clé associée à un pseudo
- la première certification peut se faire sans pseudo, mais les certification suivantes ne peuvent se faire qu’après publication d’un pseudo
- la certification contient un champ en clair “pseudo du destinataire”, cinq certification ne peuvent être validées qui si elles ciblent le même pseudo
Je pourrais très bien concevoir un client pour le duniter actuel qui n’affiche pas le pseudo. Ce n’est pas parce que cette info est en blockchain qu’elle sera affichée par les clients.
On pourrait ajouter un outil qui incite le certifieur à écrire une note sur le certifié avec des informations comme le nom sous lequel il l’a connu, les lieux et les dates des rencontres, ce qu’il sait sur lui, des photos, des descriptions physiques… Mais :
- ce n’est pas parce qu’on propose un outil que les gens vont s’en servir
- ce n’est pas parce que cet outil est proposé on-chain plutôt que off-chain que les clients vont l’implémenter
Conclusion : profitons de la wot et de quotas pour éviter les frais d’action. Il y a un vrai enjeu côté client.