le nom d’un compte en attente de création sera affiché
hm non ça va pas, là ça veut dire que tu affiches le nom Cesium+ ici pour une identité créée ? Sans même le badge nom auto déclaré ?
Car la personne ne définit son nom d’identité qu’a la confirmation, donc l’étape d’après. Ce n’est pas possible.
Là tu es en train d’ouvrir la porte aux arnaques, je peux créé un wallet nommé Chiara07, créer sont identité avec mon compte membre, et dire au genre de certifier Chiara07 en donnant l’adresse de ce wallet.
OK cette correction est donc a oublier
en l’État, il faut donc continuer a afficher l’auto nomination, donc le badge orange en plus de l’identité créée tant qu’elle n’est pas validée ?
En l’état du protocole Duniter ce n’est pas possible.
A moins de continuer comment tu le proposes, d’afficher un nom Cesium+ mais d’ajouter le badge nom auto déclaré, mais je trouve l’UX douteuse, il faut que les gens comprennent qu’ils doivent définir un nom Cesium+ à ce moment là, risque de confusion avec le nom d’identité, ect …
Je ne suis pas chaud non plus par votre volonté de pouvoir donner un nom Cesium+ a un compte membre ou je sais pas quoi, ça n’a aucun sens, risque de confusion, mélange de genre, ça va pas.
Même pour un ancien compte membre, je ne vois pas l’intéret, et c’est dangereux, confusant.
En fait là le flow est très simple: Seul le parrain (le premier certificateur) ne peut pas trouver l’identité à certifier par recherche de nom d’identité. Le certifié doit alors lui donner son adresse g1, point barre. Y’a pas à essayer de contourner ça, c’est une mesure qu’il faut standardiser, ça n’a rien de compliqué, il ne faut pas abuser.
Puis une fois parrainé, le certifié confirme sont identité, il définit à cette occasion sont nom d’identité, et à partir de là c’est bon, le second certificateur et les suivant le trouveront dans l’annuaire en cherchant sont nom d’identité.
Cela voudrait dire que l’on ne peut retrouver un simple portefeuille par son pseudo ?
Cela devient confus pour moi, je te laisse régler ce noeud
Mais là en l’occurrence comment afficher le pseudo d’un portefeuille qui a été parrainé par erreur ? Et aussi j’avais eu le même cas pour un juniste qui n’a pas eu ses certifs dans le délai de 2 mois il s’est retrouvé sans pseudo non plus.
En fait ce qui rends tous ça confu est exactement ce que je répète depuis 5 ans !!
LES NOMS CESIUM+ foutent le bordel là. Vous voulez absolument pouvoir nommer vos simples portefeuilles, très bien. Mais en l’état ça créer un mélange des genres très difficile à faire comprendre intuitivement niveau UX dans une app grand public sans créer de confusion.
Nom d’identité est STRICTEMENT différent de nom de portefeuille auto déclaré (Cesium+, offchain).
Soit tu recherches un simple portefeuille, complètement décorélé d’une identité, c’est offchain, autodéclaré. Ce n’est pas la même donnée, ce n’est pas en blockchain.
Soit tu recherche quelqu’un. Une personne. Une identité. C’est en blockchain, ça garanti l’unicité du nom et la validation par des pairs.
Le protocole offhcain peut être amélioré, déjà en empêchant les déclaration de nom qui collisionnent avec des noms d’identités, et d’autres mécansime, mais là ce n’est PAS le cas, cf toutes les discussions annexes qu’on a au sujet des données offchains.
Vous avez forcé pour ajouter les données Cs+, très bien. Mais je vous ai longuement prévenu sur les problèmes. Qui ne sont pas contournable facilement en l’état, sans commencer à entrer dans des patchs foireux côté apps, donc contournables.
J’ajouterais que dans un avenir lointain, il n’est pas impossible que le pseudo unique de l’identité soit modifiable.
C’est pour cela que la seule information fiable sur une identité est son numéro (nommé index).
Sachant cela, j’ai préconisé de toujours afficher le pseudo suivi de de l’index, sous la forme alice#1 (pseudo#index). C’est comme cela dans Tikka, et cela permet de ne pas confondre le pseudo avec tout autre nom donné au compte par l’utilisateur.
Car il n’y a pas que le profil public de Cesium+ qui permet de donner un nom à un compte, il y a aussi un nom local de travail (Tikka), un nom de vcard (contact privé).
Ainsi, dans une application on est susceptible de gérer l’affichage et la recherche par :
- pseudo identité on chain
- profil publique Césium+
- vcard contact privé
- nom local dans l’application
En bref, je conseille de toujours afficher l’index avec le pseudo : alice#1 ce qui permet d’habituer inconsciemment l’utilisateur à son numéro d’identité, et distinguer le pseudo immédiatement en cas de tentative d’usurpation comme allice#24 !
Il faut considérer qu’une identité non confirmée n’est pas une identité, et afficher le compte comme s’il s’agissait d’un simple compte sans aucune identité. Seul le propriétaire du compte devrait voir qu’il a été parrainé, tant qu’il n’a pas confirmé que ce parrainage était souhaité.
Je travaille sur un tel mécanisme sur ma PoC, je vais ouvrir un sujet dédié dans les prochain jours. Mais ça ne change pas le fait qu’une identité non confirmée ne doit pas être considérée comme une identité, mais comme un simple portefeuille, car une création d’identité peut être non sollicitée par le compte cible.
qu’est ce que tu appelles index ? l’adresse g1 ?
interessant , par contre si un autre juniste veut te certifier dans le delai il risque de tomber sur un mur sans comprendre pourquoi ! alors qu’actuellement tu vois qu’il n’a pas encore accepté !
Ce qu’il appelle index, c’est un nombre entier unique que Duniter associe à chaque identité. C’est une donnée technique, je ne pense pas que ce soit pertinent de l’afficher sur une app grand public. Pour le moment, ça se retiendrait car les nombres sont petits (5 chiffres actuellement), mais avec des nombres plus grands, les gens ne retiendraient pas ce nombre, donc ça n’aurait pas l’effet escompté. À la limite, une identicone générée à partir de l’index pourrait faire sens.
Si l’invitation est sollicitée, alors dans la pratique tu l’acceptes rapidement, sinon c’est que tu ne veux pas vraiment devenir membre. Les autres certificateurs potentiels sont censés connaître la personne, et peuvent donc la contacter directement pour savoir ce qu’il en est.
oui en effet si j’invite je contacte et suis la personne , en fait c’est quand on dépanne quelqu’un qui a un problème que ce cas se pose , comprendre ou est le problème !
mais là on revient au QRcode en fait qui s’utilise de plus en plus, du coté de nice on a un juniste qui travaille le bois et nous avait fait des planchettes avec QRcode identité et clef publique, a renouveler avec les changements mais du coup on a pris l’habitude de scanner les QRcode lors des Gmarché
Il suffit de demander à la personne qui veut être certifiée de s’authentifier sur son compte pour vérifier si elle a une invitation/parrainage en attente.
Ce n’est pas la même chose. Le QR code, c’est très bien et c’est l’idéal, mais la recherche par nom ne sert justement que quand on n’a pas le QR code de la personne qu’on veut payer.
C’est le cas où on n’a pas le QR code (ni l’adresse G1) qui fait débat.
- Vérifie comment se comporte l’app si un nom Cesium+ est définit sur un wallet membre ou ayant passé l’étape de confirmation d’identité. Le nom Cesium+ ne doit absolument plus jamais être affiché nul part.
- Vérifie le rendu de ce header pour une identité créée sans nom Cesiulm+
- Je pense que si tu pars sur ce design, il faut ajouter un contrôle dans Gecko pour empêcher la déclaration de nom Cesium+ entrant en collision avec un nom d’identité blockchain déjà existant, ainsi que refuser d’afficher un nom Cesium+ partout dans l’app si un nom d’identité blockchain correspond exactement à ce nom. Mais là ça rajoute un call RPC à chaque page wallet view et d’autres pages, wallet history par exemple, qu’il faut s’assurer de bien optimiser en batch RPC avec les autres données du storage déjà requêtés.
C’est du bricolage mais en l’absence de solution offchain adressant ces problématiques, ça me semble nécessaire.
Je ne sais si cela répond a une de tes questions mais j’ai remarqué aujourd’hui suite a une recherche sur un nom que le résultat me donnait la personne dans les résultats en auto déclaré et quand j’ai cliqué dessus cela a ouvert son compte membre validé avec son identité Audette en vert. Testé sur Anne leduc. J’ai cru a une erreur avant de comprendre que la recherche sur son pseudo césium+ amenait a son identité blockchain
Hello, je suis de retour après 3 semaines de vacances et je vois que le sujet des nom/pseudo a avancé…
Je rajoute mon grain de sel 
je vois bien tout les soucis entre noms déclarés et identité, j’ai aussi la connaissance de l’Index grâce à mon implication dans les forgerons (on le voit bien dans le panel et g1cli)
Bref, ce qu’il manque dans Gecko, c’est un affichage clair et distinct du nom déclaré dans Cesium+ que l’on peut mettre sur notre profil mais qui actuellement ne s’affiche pas quand on va voir le détail du Profil.
Et le nom du portefeuille qui est aussi ce nom “Cesium+” affiché et qui porte à confusion. On voit bien dans Cesium² la distinction entre le nom du portefeuille, le nom et prénom du propriétaire du portefeuille (si on veut le préciser) et les infos complémentaires du profil Cesium+.
Et tout ça, bien différencié du pseudo = identité membre (avec index qui peut être mis à titre indicatif dans les détails du profil).
Concernant les dernières modifs de mon côté, j’ai poussé la MR fix(a11y) : amélioration accessibilité TalkBack — boutons certif, drawer, écran portefeuilles (!125) · Merge requests · clients / Ğecko · GitLab
Bonjour,
Vu que Gecko voit de nouvelles versions régulièrement, est-ce que le site de traduction Gecko @ Weblate pourrait être mis à jour avec les nouvelles chaînes, afin qu’on puisse compléter/corriger les traductions si besoin ?
Merci à vous tous pour ces évolutions. Gecko est vraiment une appli agréable à utiliser.
je ne sais pas comment cela se fait , mais normalement l’IA a a chaque fois utilisé des traductions existantes ou en a créé de nouvelles .
par contre n’ont ete prises en compte que les 6 langues actuelles
Oui, j’ai vu que des traductions avait été rajoutées automatiquement, l’IA a fait du bon boulot, mais peut-être qu’il y aura des trucs à ajuster.
j’ai voulu m’inscrire a weblate mais le lien et le bouton de confirmation de l’email est en erreur 404
ainsi que le contact !
j’ai ecris via le formulaire sur le site