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à. 
1 Like
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 ?
1 Like
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.
1 Like
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 !
1 Like
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. 
3 Likes
À 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.
1 Like
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
1 Like
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 :
- Gestion fine des comptes et dérivations (notamment des one-shot accounts)
- Gestion avancée des virements (automatisés, avec délai de récup, atomic swap, etc).
- Historiques et graphiques nombreux pour la comptabilité (dès que les indexeurs « officiels » seront prêt).
- Comptabilité en double entrée
Par contre :
- Pas de création/certification des identités (elle seront juste affichées).
- Pas de Wot
- Pas de gestion technique des serveurs forgerons.
- Pas de votes pour le runtime.
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.
1 Like
Comme tout membre forgeron est censé maîtriser la ligne de commande, je pense que c’est plutôt à un utilitaire en ligne de commande de fournir ce qui est utile aux forgerons
Par contre pour tout ce qui est gouvernance on-chain, on aura besoin de logiciels qui cibles bien le type d’utilisateurs qui aura le droit de voter, les besoins vont dépendre des décisions prises là-dessus, cf ce sujet: Dissocier le droit de forger du droit de voter les runtime upgrade
2 Likes
Pour les votes effectivement, ça peut être intéressant.
Mais je pensais que seul les comptes membres pouvaient voter.
Faudra voir si une entreprise (une personne moral sans compte membre) peut voter sur tel ou tel sujet.
Je reviens sur les dérivations, car je crois avoir compris le malentendu (que c’est dur de s’exprimer à l’écrit 
).
Tikka ne se comportera pas comme Gecko, car l’utilisateur a son compte root par défaut et on pourra faire des dérivations libres. Donc n’appliquera pas la convention « de comportement par défaut » de Gecko et des clients pour le grand publique. Ce qui est normal pour un logiciel de comptabilité.
Mais la RFC sera proposée et même mise en avant. Elle permet de simplifier tellement la gestion des dérivations. Notamment des one-shots accounts.
Désolé si j’ai fait croire à un refus de la RFC. C’était pas le but.
Je répond sans animosité aucune hein, j’ai l’impression que cette discution monte en pression inutilement ^^
Pourquoi ne pas présenter la dérivation 2 par défaut ?
Pourquoi ne pas juste masquer totalement la dérivation root, sauf si explicitement généré sur demande custom ?
Si tous les wallets comme Gecko et g1-compagnon génèrent //2 par défaut et non root, ce sera Tikka qui aura un comportement anormal aux yeux des utilisateurs.
J’ai encore du mal à comprendre les raisons réelles de ce choix.
En quoi est-ce “normal pour un logiciel de comptabilité” de ne pas générer les mêmes adresses que le reste de l’écosystème monétaire ?
La RFC ne stipule nullement l’utilisation du compte root, et je pense qu’on devrait l’amender pour expliquer que l’utilisation du compte root est fortement déconseillé.
Pas de souci de mon côté tant qu’on reste sur des arguments techniques. Le mieux c’est qu’on s’appelle, c’est plus simple pour se comprendre. Je t’envoie un sms.
2 Likes
Et s’il y avait un paramètre « dérivation par défaut », dont la valeur par défaut serait « //2 » ?
Et aussi un « mode expert » ajoutant un champ « dérivation » où il faut ?
Ça permettrait la compatibilité sans prise de tête pour le commerçant, et la flexibilité sans trop d’effort pour l’informaticien.
1 Like
Non mais en on s’est eu au phone avec vit, c’est très bien si il veut fournir un outil complet pour avoir le contrôle, partir de root et pouvoir dériver ce que tu veux.
En fait je suis en train de préparer un scan des 30 premières dérivations + root lors de l’import d’un nouveau mnemonic.
Si root ou n’importe laquelle des 30 premières dérivations son inscrites en blockchain, alors elle s’afficheront comme portefeuille dans ton coffre directement.
Si chaque client fait ça, ça répond à tous, chacun peut bien créer les dérivations qu’il veut par défaut, elles seront détectés lors de l’import ailleurs.
1 Like
J’ai corrigé une grosse boulette dans l’exemple qui se disait opaque sur une dérivation //2 (transparent)…
J’en ai profité pour publier sur le dépôt des RFCs.
1 Like
Je n’ai trouvé aucune justification qui explique pourquoi on devrait faire ce choix. De plus, la discussion ci-dessous ne résout pas la question de ce qu’un client doit faire si le compte membre est trouvé sur une dérivation à laquelle il ne s’attendait pas.
Pour moi, c’est bien de se mettre d’accord sur une norme pour dériver des comptes d’un même secret, parce que ça permet par exemple la découverte automatique, mais c’est gênant si on le cache à l’utilisateur et que ça donne lien à des frictions lors du passage d’un outil à l’autre.
De plus, je pense que le principal est de garder le comportement par défaut le plus simple possible (un secret = un mnemonic pur = un compte) et de ne proposer les dérivations que comme un “plus”, une fonctionnalité optionnelle pratique. Si on se met à mettre des dérivations par défaut, on se met des bâtons dans les roues quand il faudra l’expliquer.