Lors d’une discussion hier avec @kimamila, on a parlé du parcours d’un nouveau membre en v2. Il s’agit de distinguer les bonnes pratiques, et la facilité d’accès.
En v1 il est possible de commencer sans une seule Ğ1 et de déclarer un pseudo membre comme première action. Le premier certificateur peut alors chercher le pseudo dans l’annuaire pour certifier.
C’est possible car ces actions n’ont d’effet qu’en piscine, qui joue un rôle de “sas d’entrée” avant que quoi que ce soit arrive en blockchain. L’avantage est que la friction à l’entrée est minimale, les inconvénients sont multiples :
pas de consensus sur les inscriptions, on peut se retrouver avec plusieurs dossiers d’adhésion en parallèle avec le même pseudo, qui reçoivent chacun des certifications
sensible au spam, on peut assez facilement saturer les piscines avec des fausses demandes d’adhésion avec des noms courants, ce qui force à saisir la clé publique
C’est pour ces raisons que les piscines ont été retirées en v2, et toutes les opérations d’identité sont inscrites immédiatement en blockchain. Mais cela implique que :
un compte sans monnaie ne peut rien faire (même si les frais de transaction sont remboursés, il faut quand même avoir un compte avec le dépôt existentiel, un nonce et pouvoir avancer les frais)
la réservation du pseudo est absolue dès la confirmation, il ne peut pas y avoir plusieurs dossiers pour le même pseudo en même temps
Mon idée pour les clients v2 était d’inciter aux bonnes pratiques, c’est-à-dire de ne permettre la création d’identité que pour un compte qui a déjà des Ğ1, et d’inciter la confirmation de contrôle de compte par des transferts symboliques de 1 Ğ1. Ça donnerait quelque chose comme ça :
Bob crée un secret et dérive une paire de clés.
Bob transmet sa clé publique à Alice par le moyen de son choix (scan, sms, mail…).
Alice fait un virement de 10 Ğ1 à Bob (un paiement, un don, peu importe).
Bob fait un virement de 1 Ğ1 à Alice pour montrer qu’il contrôle bien son compte.
Alice effectue les vérifications habituelles (confiance en Bob, possession du doc de révocation, pratiques de sécurité…).
Alice crée une identité pour Bob avec une première certification.
Bob nomme son compte et peut recevoir les autres certifications.
Le premier certificateur à remplir les deux critères (5 certifs et règle de distance) demande l’évaluation de la règle de distance par la blockchain, ce qui valide l’identité.
Mais Benoit insiste pour qu’on trouve un moyen pour rendre le parcours aussi simple qu’en v1. Nous avons évoqué la possibilité de passer par un système hors chaîne intégré à l’application ce qui donnerait ceci :
Bob pré-réserve un pseudo dans un système hors chaîne (donc sans consensus et sensible au spam, mais en trouvant des astuces pour que ça marche le plus souvent).
Alice cherche le pseudo de Bob dans un annuaire et confirme éventuellement la clé à l’oral.
Alice crée l’identité pour Bob, et lui transfère 10 Ğ1 s’il n’en a pas.
Bob confirme son identité (dans la plupart des cas avec le pseudo pré-réservé, mais il est possible qu’il ne soit plus disponible entre temps et qu’il doive changer). Il peut alors recevoir les autres certifications.
Comme “8” dans l’autre scénario.
Je serais curieux de connaître les avis des junistes à ce sujet.
Cesium² doit inciter aux bonnes pratiques avec un parcours membre plus complexe.
Cesium² doit viser la simplicité avec un système hors chaîne intégré à l’appli.
Autre : lâchez vous en commentaire
0voters
Reste à concevoir un système hors chaîne pour la pré-réservation des pseudo…
Les différences que je vois entre les deux process sont :
dans le second, le pseudo peut être préréservé, pas dans le premier.
dans le second, Alice peut chercher Bob par son pseudo, c’est plus facile pour elle.
Il me semble pertinent que les utilisateurs commencent par utiliser leur clef publique adresse plutôt que leur pseudo, pour savoir que c’est ça l’identifiant unique de leur compte.
Il me semble également pertinent que la réservation du pseudo ne soit pas détachée de la demande confirmation d’identité.
Je pense d’autre part que, si Bob a préréservé son pseudo et doit en changer lors de la confirmation d’identité, ce sera source d’incompréhension. Il est plus clair de dire tout de suite que le pseudo se choisit lors de la confirmation de l’identité et pas avant.
Le fait que les clients montrent les bonnes habitudes est une bonne chose. L’implémentation d’un nouveau système de pré-réservation de pseuds en plus du système de messages stockés sur IPFS me semble ajouter une complication de trop.
Une amélioration que je peux voir dans le process 1 serait de faciliter l’envoi de la clef publique à Alice. Une UX pourrait être :
Bob crée un compte
Bob indique qu’il souhaite que ce compte soit membre
l’UI demande des moyens de joindre les certificateurs potentiels (email ou téléphone ,par ex, suivant le contexte (bureau ou mobile))
l’UI crée les liens (typiquement un href="mailto:… ou un href="sms:…) avec un message par défaut contenant l’adresse pour laquelle Bob veut créer une identité. (ces liens peuvent contenir un corps de message, et mailto peut contenir un sujet)
Bob clique sur le lien, arrive sur son application email/texto et peut envoyer sa demande directement
edit - pour moi, ce que tu présentes comme un parcours “plus facile” (le second) est au contraire plus sujet à duplicatas, conflits et bugs.
re-edit - je pinaille, mais le second process ne vise pas la “simplicité”, mais la “facilité”, c’est très différent. Le premier process est au contraire plus simple, car moins de moyens techniques sont mis en place. #KISS
Dans le 2éme déroulé il manque des étapes :
1 : Bob doit d’abord créer sa paire de clé, dans tous les cas.
2 : Bob préserve un pseudo
3 : Alice cherche le pseudo de Bob dans l’annuaire et confirme la clé l’oral
4 : Alice vérifie que Bob a assez de Ğ1 et lui transfère s’il n’en a pas
5 : Alice effectue les vérifications habituelles (confiance en Bob, possession du doc de révocation, pratiques de sécurité…). Je ne vois pas pourquoi on devrait se passez de cette étape !
6 : Alice créer l’identitée pour Bob
7. Bob confirme son identité, il peut alors recevoir d’autres certifs
8. 1. Le premier certificateur à remplir les deux critères (5 certifs et règle de distance) demande l’évaluation de la règle de distance par la blockchain, ce qui valide l’identité.
Finalement ce n’est pas plus simple ! Donc pourquoi ne pas favoriser les bonne pratique.
La recherche dans l’annuaire se fait souvent sur le champ “nom, prénom” de césium.
Perso, je déconseille toujours d’ouvrir un compte membre. Je souhaite depuis longtemps que cette option disparaisse de cesium.
Je pense pareil que les deux commentaires précédents.
De plus je considère que le pseudo est vraiment la pire chose sur laquelle s’appuyer pour confirmer une identité sur un compte. Cette information n’étant pas en blockchain stricto sensu et n’etant facilement accessible que via squid.
Je profite donc de ce sujet pour rappeler ma proposition de donner toute son importance à l’index de l’identité et à l’adresse du compte.
Le pseudo ne doit pas avoir plus d’importance que le prénom dans un profil cesium. C’est une aide, auquel il ne faut pas accorder plus de confiance. Amha.
Ce qui permettrai d’en changer quand on veut et même d’avoir des doublons. Comme un avatar.
Par contre l’inverse n’est pas vrai : si tu as uniquement la clé ou l’index, pour trouver le pseudo sans parcourir toute la map (ce qui reste assez léger), il faut passer par l’indexeur squid.
Mais il y a déjà eu beaucoup de discussions à ce sujet, qui aboutissent plutôt à la conservation d’un pseudo unique.
Pour avoir suivi les discussions, il était question de supprimer le pseudo car il est inutile si on a le numero d’index de l’identité. C’est ce qu’avait tres bien constaté Elois.
L’idée de le conserver n’est donc pas dû à une exigence technique, mais au fait que les utilisateurs humains sont attachés à ce pseudo. Un constat issue de la pratique de Cesium.
On a alors enfreint la règle d’or DRY en stockant ce pseudo en blockchain et la règle de la source unique de vérité en s’assurant qu’il soit unique.
Je me permets de réaffirmer que sous sa forme actuelle, unique et en blockchain, le pseudo est une information inutile pour la blockchain, avec une implémentation qui enfreint deux règles de bonne pratique de programmation.
Je propose toujours de rendre le pseudo libre pour l’utilisateur, non unique.
Il suffirait de retirer les règles d’unicité du pseudo et de ne le stocker que comme évènement extrinsic on block accessible via Squid. Ainsi on serait plus propre dans le code et offrirait plus de souplesse à l’utilisateur sur son pseudo.
Je pense qu’il faut faire attention à ne pas tromper les gens sous prétexte de leur simplifier la vie.
Comme cela a été fait avec “identifiant secret” et “mot de passe” qui fait croire à beaucoup de gens qu’ils se connectent à un compte alors qu’en fait, ils créent une paire de clé. C’est boulot monstre ensuite pour expliquer que la clé est calculé à partir de leur saisie…
J’entends les arguments obligeant à une meilleure pratique.
Mais il faut autant que possible faire une migration iso-fonctionnelle.
Pour solutionner ce cas d’utilisation, il suffit juste d’un annuaire (profil dans un datapod) accessible dès la création d’un compte. Ça me parait assez simple… et déjà prévu ! (mis à part l’antispam)
On n’a pas du tout besoin des pseudos (UserID) pour cela. Juste un profil (title, avatar, etc. ) associée à un clef/adresse. De toute manière, encore une fois, on avait prévu de le faire pour les comptes d’asso, etc. La question est juste de savoir comment gérer l’antispam de ces profils, dans la mesure ou l’utilisateur n’a pas encore de monnaie sur le compte.
Comme @Maaltir, j’ai observé de nombreuses incompréhensions et frustrations liées au fait que le compte membre peut être créé à la première connexion (typiquement, quelqu’un crée son compte membre avant de rencontre qui que ce soit, puis comprend qu’il doit rencontrer des gens, puis voit son adhésion périmer au bout de deux mois… Sans parler des mots de passe faibles qu’on conserve sur le compte membre parce qu’il existe déjà.
Le fait d’enlever la possibilité de créer un compte membre directement serait un progrès, amha. Et la migration sur Duniter2 serait une belle occasion de le faire.
Je vois deux cas d’usage, l’un légitime et l’autre néfaste.
Ici on parle de pouvoir associer un pseudonyme non unique à une adresse dont le montant disponible est nul. Je trouve cette fonctionnalité légitime pour des gens qui commencent dans la Ğ1, pour faciliter leurs premières ventes, en facilitant le fait de les retrouver.
Je trouve en revanche cette fonctionnalité néfaste si on doit garantir l’unicité du pseudonyme et le réserver car il deviendrait l’identité du compte sur la BC. Ceci masque à l’utilisateur la progression réelle de sa demande d’identité.
OK, donc la proposition n’est pas de pré-réserver les userID (ce que j’avais compris dans le post initial de @HugoTrentesaux), mais simplement d’avoir un système d’anti-spam qui ne fait pas intervenir de monnaie, pour un annuaire déjà prévu. Je n’y vois pas d’inconvénient.
Je sais que la PoW est utilisée par Nostr pour de l’anti-spam, ça pourrait être une piste.
et je maintiens ma proposition de faciliter l’envoi des demandes d’invitation par un lien mailto/sms, pour ce qui concerne le processus de certification.
En v2, grâce à l’index de l’identité, le pseudo devient une information fournie par l’utilisateur et exactement de même nature que le profil cesium. Et les datapods serait un bon endroit pour les accueillir.
Je n’ai pas pu suivre car en voyage, mais mon avis : l’idéal est que ce soit le plus facile possible tout en encourageant les bonnes pratiques, sans rendre impossible ni trop peu pratique de les outrepasser, ni rendre les sécurités hors-chaîne bloquantes.
Exemples :
mode expert qui active les boutons pour outrepasser les tests hors-chaîne ou les étapes non absolument obligatoires
possibilité de prendre un pseudo même si il a déjà été réservé hors-chaîne (avec avertissement)
possibilité de pré-créer une identité sans G1, mais avec avertissement et appels à l’action (voulez-vous plutôt créer l’identité sur votre autre portefeuille qui a des G1, transférer, demander à quelqu’un de transférer, changer une identité de compte)
