Je ne vois pas comment utiliser la monnaie déposée sur mon compte ğannonce. Le fichier trousseau de clés contient la clé publique et, semble-t-il, la clé privé du compte. Mais quid des identifiants secrets réclamés par Sakia et Cesium ? Merci de me dépanner.
1 Like
J’attendais cette réaction !
Ceux qui utilisent la fonction “générer un trousseau” via ğannonce ne peuvent en effet pas envoyer de monnaie via Sakia ou Cesium, qui ne fonctionnent pour l’instant qu’avec couple d’identifiants secrets (appelée aussi la méthode scrypt).
Silkaj est plus avancé dans ce domaine, car il propose aussi l’authentification :
- par seed, un gros nombre duquel on dérive le trousseau (seed donnée via ligne de commande ou via fichier)
- par WIF (format hexadécimal contenant la clé privée)
Mais aucun ne gère spécifiquement le format de fichier de ğannonce, qui d’ailleurs ne respecte aucun standard particulier. C’est un simple fichier YAML au format :
pub: clé publique en base58
sec: clé secrète en base58
Il leur faudrait gérer ce cas pour pouvoir envoyer de la monnaie avec le trousseau ğannonce, car retrouver les identifiants secrets à partir du trousseau final est une opération considérée trop coûteuse en temps/énergie. Scrypt a été développé dans ce but.
2 Likes
Une fois ceci compris et testé un contributeur Ğ1 efficace et opérationnel en fera une documentation simplifiée afin de faciliter la compréhension des nouveaux entrants.
Donc, si je comprends bien, je ne suis pas prêt de récupérer le produit de mes ventes 
.
Je ne sais pas, il suffit d’un commit sur le dépôt Silkaj !
D’ailleurs ça m’a l’air accessible, ça semble être dans cette portion du code (22 lignes).
Là tout de suite non.
Mais, peut être que @Tortue peux le faire.
Sinon, je peux accepter une mission payée en Ğ1 !
1 Like
Passe une annonce…
Hello, il faudrait se mètre d’accord sur les formats de fichier a utiliser pour les “file wallet” et les "file wallet chiffré"
il y a déjà dans silkaj l’authentification par fichier, mais qui n’est pas dans le même format que ğannonce (c’est la seed brut)
Je ne cherche pas à faire la promotion du format WIF et EWIF (qui signifie [Encrypted] Wallet Import Format),
mais pourquoi ne pas stocker ces formats directement dans les fichiers, plutôt que de réinventer la roue?
Il faudrait faire ce travail assez rapidement, pour ne pas se retrouver pour les clients à gérer 50 formats différents en fonction des applications.
Mais si tel doit être le cas, le mieux serait probablement une extension de fichier particulière pour dire quel est le format utilisé pour éviter à l’utilisateur de saisir le format du fichier utilisé.
Et si c’est du yaml ou json ou autre, avoir des clefs bien définies pour connaitre le format des valeurs
ex:
walletG1.seed
walletG1.wif
walletG1.ewif
walletG1.yml (avec bien les champs “pub” et “sec” ou alors “seed”, …)
walletG1.json (idem)
3 Likes
Je suis tout à fait d’accord, je ne comprends pas vraiment pourquoi cgeek a choisi d’utiliser un yaml custom 
C’est entre autre pour ça que j’aimerai qu’on déporte ces fonctions de silkaj vers duniter-python-api, pour utiliser une référence standard dans nos clients par la suite.
Ca me fait penser, pour le JS, il n’y a pas de librairie commune Cesium / gannonce / … ?
2 Likes
Moi j’avais fait ça: https://duniter.tednet.fr/paperwallet/lib/duniter_tools.js
pour ne pas que tout le monde se retape le taf d’import/export des formats WIF/EWIF en JS
C’est vrai quoi, serait-il idiot ? D’ailleurs pourquoi les humains inventent-ils constamment des choses plutôt que reproduire ce qui est connu ? Par exemple pourquoi Stéphane Laborde a-t-il inventé la “monnaie libre”, alors même qu’il existait le format standard “monnaie-crédit” ? Et puis pourquoi la monnaie libre ? On sait bien ce qui est valeur ou pas !
Mouarf 
Aussi, je le répète pour ceux pas encore au courant bien que je l’ai annoncé dans ce billet : ğannonce est un prototype technique, volontairement imparfait pour que ses lacunes ou mauvaises fonctionnalités grattent suffisamment des développeurs pour leur donner envie de produire mieux.
Et je peux même vous annoncer un truc très très fort : ğannonce est capable de détecter le format d’un fichier sans son extension ! Sisi ! La légende raconte même qu’il serait capable du jour au lendemain de passer au format WIF/EWIF avec rétro-compatiblité !
Mais bon, c’est une légende … ou un truc de développeur, on sait pas trop.
Disons que là j’ai peur qu’on se retrouve avec un format de plus à maintenir 
Je comprends bien la démarche, à titre personnel, je n’aurais carrément pas implémenté de chargement de clé par fichier ^^
Enfin bon, in fine c’est une bonne manière de motiver les développeurs à contribuer et à prendre ğannonce en main.
1 Like
Ah bah justement je voulais te demander le format du fichier. Cool, on a notre specificiation 
je vais me faire un ticket pour Cesium
OK, alors partons sur l’implémentation de la détection et la gestion des formats de fichier:
- yaml
- seed simple
- wif
- ewif
dans tt les clients et dans gannonce.
Duniter vient de débuter et on a déjà fait plein de formats différents.
Bon bas pourquoi pas…
Cette discussion me fait penser au fait qu’on a pas un bugtracker commun pour les projets logiciels qui tournent autour de Duniter.
Dans ce cas on cherche à normaliser le format d’un fichier. Si on avait un ticket sur cette problématique, ça serait aller plus vite et non à droite à gauche sur le salon de discussion et sur le forum.
Pareil pour le développement des API customs…etc
Ces problématiques sont générales et non liées au dépôt de développement d’un logiciel.
On veut que les logiciels Duniter fonctionnent en interaction avec les mêmes protocoles, les mêmes standards, les mêmes spécifications, et les mêmes normes.
Les tickets globaux permettent que tous les acteurs discutent d’une problématique commune et une fois celle-ci acceptée, que ces acteurs la mettent en place dans les différents logiciels.
C’est une problématique qu’on a rencontrée dans le projet YunoHost à laquelle on a répondu en mettant en place un bugtracker commun.
Je dis pas qu’il faut qu’on se lance dans la mise en place d’un bugtracker commun aux projets de Duniter.
Je dis, que cette limitation de GitHub freine le développement du projet Duniter.
Et alors ? Même dans 10 ans, je pourrais me pointer et créer 500 nouveaux formats différents : est-ce qu’on viendrait alors me dire « Duniter a à peine 10 ans et on a déjà plein de formats différents. » ?
De même il existe plein de fichiers avec l’extension .c, pourtant tous ne respectent pas la même norme de C. Est-ce un problème ? Les compilateurs ne sont-ils pas capables de détecter la version / le format du fichier ?
N’as-tu pas déjà vu des logiciels dans lesquels tu ouvrais un fichier sans extension et pourtant le logiciel devinait le format du fichier ?
Je ne vois pas pourquoi on ne saurait pas faire pareil.
Ce n’est pas parce que je crée un format pratique pour moi dans ğannonce (en termes de développement) qu’il doit forcément être adopté ! Regardes : tu as produit le format WIF / EWIF (ou alors tu l’as repris, je n’en sais rien) : est-ce que ça a obligé Sakia et Cesium a réutiliser ce format ?
Ou encore, ce n’est pas parce que des gens ont définit à un instant t que le contenu d’un fichier .c serait du C89 que de futurs développeurs n’ont pas pu y mettre du C99.
A la limite, si Sakia / Cesium / Silkaj implémentaient tous une même technique, il y a de fortes chances que les logiciels suivants l’implémentent aussi. Mais il n’y a pas besoin de se mettre d’accord pour cela ! Il suffit de créer et à d’autres d’adopter.
Que se passe-t-il pour ceux qui ne veulent pas ?
1 Like
Ils font différemment. Tout simplement.
C’est pas si mal au final.
Ça me paraît être une bonne philosophie pour un relativiste : on fait des trucs, et il se peut que certains soient d’accord. Ce qui n’a pas besoin d’impliquer que tous doivent l’être pour avancer, ni que ceux qui ne sont pas d’accord doivent subir une contrainte de ceux qui sont d’accord.
Il faut aussi trouver le point d’invariance.
1 Like