Non, je comprends bien que niveau UX on doivent d’abords générer son compte membre (//0), puis se faire certifier dessus.
Je dis simplement que rien n’emêche de se faire certifier //2, et qu’il faut bien traiter ce cas dans l’app, sinon on se retrouve avec un portefeuille membre mais traité comme un non membre.
Donc que dans tous les cas, il faut vérifié l’état de l’idty de chaque dérivation présentes dans un coffre.
Edit: Oui c’est pas faux…
Et alors ? En quoi ça poserai problème ?
Je ne comprend toujours pas pourquoi, pour moi tu n’a besoin de vérifier que //0
… Oui pas tant que ça au final, j’avais surtout en tête nos histoires de longueur de code secret variable en fonction de la présence d’un compte membre ou non, mais je ne vais pas garder cette feature, beaucoup trop compliqué à gérer côté UX.
Plus généralement, pour toutes les conventions qui ne peuvent pas être garanties par la blockchain, tu aura toujours des cas possibles qui ne sont pas prévus suite à l’utilisation de wallet modifiés/piratés.
Si tu essaye de gérer tout les cas possibles tu ne va jamais t’en sortir, je te recommande de ne gérer que les cas prévus par les conventions adoptées, en tout cas c’est comme ça que je ferai si je devais développer un wallet 
Oui tu as raison.
Bon du coup j’en profite pour dire qu’on peut dès maintenant suivre l’état de l’identité de chaque wallet dans Gecko, confirmer son identité le moment vue, et suivre l’état du status
Bon par contre pour le moment c’est avec une UX minimal, et c’est « yolo je peux faire ça sur toutes mes dérivations », mais c’est juste pour les débuts de la gdev.
Ca sera dans le prochain build.
Tikka aussi supporte les chemins de dérivation en import, ce n’est pas vraiment le problème.
Le problème c’est que Gecko, en cachant la dérivation, fait croire à l’utilisateur qu’il créé une adresse à partir du mnémonique. Ce qui est faux. Toi tu le sais, Elois aussi je crois, mais personne d’autre si on ne lit pas intensément le forum comme moi. Et même moi qui l’avait lu, j’avais oublié sinon j’aurai compris plus vite. le problème des adresses différentes.
Du coup les utilisateurs qui arrivent dans Tikka tapent ce que Gecko leur a fait croire et obtienne une adresse différente.
Je ne suis pas contre les dérivations, au contraire, et surtout sur mobile, je trouve cela plus sécurisé.
Mais Tikka se veut un client complet (donc on peut faire des comptes root) qui ne cache rien à ses utilisateurs. C’est sa philosophie.
Je sais que c’est difficile d’afficher des choses pas faciles à comprendre pour l’utilisateur, mais cette “incompatibilité” de Tikka et Gecko n’existe que par ignorance d’une action cachée de Gecko.
Et aussi (je vais corriger ça dans l’interface) parce que Tikka ne précise pas qu’il accepte en import des chemins de dérivation.
Le but c’est justement tous l’écosystème Ğ1 soit designé ainsi!
L’utilisateur n’a pas besoin de savoir que c’est //2 si tous les clients Ğ1 démarrent sur //2 comme premier wallet.
Si Tikka tu veut permettre de créer toutes les dérivations c’est très bien, mais faut savoir si on se met d’accords sur:
//0: Compte membre uniquement
//1: Première dérivation opaque
//2: Première dérivation transparente, créé par defaut
root: doit être généré que sur demande
Si on ne se met pas d’accords là dessus, alors je ne peut pas garder ce mécanisme dans Ğecko, et il faut qu’on se mette d’accords sur autre chose.
Mais dans tous les cas, il faut qu’on se mette d’accords sur quelle adresse est considéré comme l’adresse par défaut d’un mnemonic dans l’écosystème Ğ1, root ou une dérivation ?
Si Tikka est orienté grand public pro par exemple, il faut que ce soit cohérent avec Ğecko et le reste.
Si il est orienté utilisateurs avancés uniquement, alors dans ce cas tu peux peut être générer root par defaut et permettre de tous faire dans l’interface par defaut, mais dans ce cas il faut traiter Tikka comme outils pour utilisateurs avancés uniquement, pas pour qu’un commerçant ou un membre lambda l’utilise quotidiennement pour ses actions.
On est d’accord que tu n’affiches pas dans l’interface tous le processus pour passer du mnémonique jusqu’à ton adresse root ?
Que tu utilises tel algo de crypto, tel format, tel prefix 42, ect … ?
Donc tu ne peux pas dire que Tikka “ne cache rien à ses utilisateurs”
S’arrêter à root au lieu de dériver en //2, c’est juste un choix arbitraire que tu fais, en te calquant sur ce que fait l’extension polkadot.js au lieu de notre RFC.
Je pense que c’est illusoire de croire qu’on peut imposer à tous les clients une seule façon de faire.
Surtout si cela n’est pas imposé par le protocole de la blockchain.
Pour Tikka en tout cas, je ne souhaite pas appliquer cette convention pour l’instant.
C’était pourtant bien le cas avec les ID/MDP Cesium.
J’espère que vous allez réussir à vous mettre d’accord parce que moi j’ai du mal à comprendre les tenants et aboutissant de ces trucs-là. 
D’après ce que j’ai compris, pour l’instant je peux importer dans Tikka un compte que j’ai généré dans Gecko en ajoutant le //2.
Par contre, si j’avais généré ce compte dans Tikka, je n’aurais pas pu le récupérer dans Gecko. Ai-je bien compris ?
Proposition au cas où vous n’arriveriez pas à vous mettre d’accords :
Lors de la saisie du mnémonique, indiquer les différentes clés dérivées de ce compte et laisser le choix à l’utilisateur de la (ou les) clés qu’il souhaite importer.
Ou n’autoriser l’import d’un compte que s’il existe déjà dans la blockchain, comme çà on risque moins de se tromper. (j’avais déjà pensé à cela pour les comptes venant de la V1)
Est-ce faisable ou complètement farfelu ?
Oui jusqu’à ce qui soit possible de choisir une dérivation dans Tikka et de savoir qu’il faut choisir la seconde.
Non ce n’est pas farfelu, c’est une bonne idée étant donnée que Duniter v2s nous permet de savoir si une address est active ou non.
Cela dit cela ne concerne que l’import de mnemonic existant, pas l’onboarding.
Je pense être d’accord avec cela, si “l’onboarding” correspond bien à la création d’un nouveau compte. Parce que je ne suis pas sûr du sens de ce mot…
Oui la création de nouveau compte.
Merci d’assumer ce choix, qui transparaissait déjà dans tes choix d’UX, et qui confirme que Tikka ne sera jamais un client grand public, mais un sakia 2.0.
Du coup pour Mme. Michu, sur son PC, c’est encore Cesiumv2 qui va s’imposer, à défaut d’autres wallet grand public sur desktop, c’est triste 
@poka les conventions communes me semble essentielles entre les wallet tout public, mais Tikka n’est définitivement pas tout public, donc on s’en fout.
@poka je pense qu’il reste important de discuter avec @kimamila et @ManUtopiK pour essayer de vous mettre d’accord sur des conventions commune entre Ğecko, CesiumV2 et Ğ1companion, les 3 seuls projets à ce jour qui me semblent viser le tout public !
J’ai peut-être mal compris mais je n’ai pas l’impression que @vit dise ici qu’il veut faire un outil pour expert exclusivement.
Un outil peut très bien être à la fois grand public facile à adopter mais difficile à maîtriser pleinement (car remplit d’options que seuls les experts exploitent). C’est le cas de nombreux logiciels comme Excel par exemple, ou encore les jeux de Blizzard comme Diablo.
Enfin le mieux serait que vit précise son approche.
À condition que les options pour expert soi masquées par défaut, ce qui implique de cacher des choses aux utilisateurs «par défaut».
Mais je pense que l’incompréhension réside dans le fait qu’on n’entend pas la même chose derrière “tout public”, ou qu’on ne met pas la barre au même niveau.
Pour moi, un projet “tout public” c’est un projet qui vise à rendre son application “intuitive”, c’est à dire que l’on est pas besoin d’expliquer à l’utilisateur comment utiliser l’application, il y a des gens dont c’est le métier de concevoir des interfaces intuitives, malheureusement on le les accueille pas…
Même Cesium n’est pas intuitif, et pour moi c’est l’un des (pas le seul) freins à l’adoption plus large de la Ğ1.
Vous ne vous rendez pas compte de la violence de vos propos, et de vos jugements, uniquement liée à de la frustration :
Pfff lire encore ce genre de phrase défouloir au milieu d’une discussion technique, me désole.
Merci cgeek, tu l’as très bien fait, et moi même, je n’ai cessé de le faire.
Tikka sera utile, j’espère, pour les entreprises, les comptables et les commerçant (pour leur compta), c’est l’objectif. Car je souhaite bien plus à la June V2 qu’une monnaie de gmarché. C’est un gros gros pari que je fais sur cette migration Substrate, pour apprendre et contribuer.
Les choix techniques sont fait pour cet objectif ambitieux dès le départ (Python, Qt).
Alors détendez vous, respirez par le nez. Moi je fais une pause jusqu’à la prochaine visio.
Désolé @vit je ne voulais pas te froisser, mais je ne vois rien de violent dans mes propos, juste le constat que tes choix pour Tikka ne sont pas compatibles avec une vision grand public, et tu en as tout à fait le droit, mais il faut l’assumer
Ce n’est pas du grand public, et ce type de professionnels aura de toute façon besoin d’être formé, et puis quand on doit interagir avec une interface pour le boulot, on est beaucoup plus enclin à surmonter les difficultés de l’interface car on doit le faire “pour le boulot”.
Pour un usage perso/particulier les gens n’ont par contre pas envie de se prendre la tête, donc faut que ce soit intuitif, mais si tu ne vises pas les particuliers alors c’est bon
EDIT: De toute façon pour les particuliers, les vrais utilisateurs finaux, la masse, le desktop c’est dépassé, le simple fait d’installer un programme desktop beaucoup de gens ne savent pas/plus le faire, donc mobile + web pour la masse c’est suffisant, du coup je garde espoir qu’on puisse enfin cibler le grand public correctement avec Ğecko + extension Ğ1-companion/Ğ1connect
Tout à fait d’accord sur le fait qu’une appli bureau n’a aucun intérêt pour un particulier. Je l’ai dit de mémoire dans mes premières annonces du projet Tikka.
Le seul intérêt de Tikka c’est pour les entreprises, investisseurs, comptables, financiers, etc.
D’ailleurs l’enthousiasme de la phase de démarrage technique de Duniter V2 a failli me faire ajouter des fonctionnalités inutiles pour les entreprises, comme la gestion des session keys pour les forgerons.
Donc dans Tikka :
Par contre :
Même si rien n’est figé et que cela peut évoluer selon les demandes des utilisateurs.
Je pense que la roadmap est claire maintenant.