J’ai fait une issue pour la commande tx-history, mais je n’ai pas le droit de me l’assigner.
Dans l’avis de licence, tu as laissé « either version 3 of the License, or (at your option) any later version », or dans Cargo.toml c’est « AGPL-3.0 », donc la licence est-elle AGPLv3 ou AGPLv≥3 ? Autoriser les versions ≥3 me paraît une faille de sécurité (c’est faire confiance aveuglément à la FSF et l’autoriser à retirer des restrictions de la licence du code).
Ce n’est pas prioritaire, mais pour que le client soit pratique à utiliser il faut qu’il supporte la panne du nœud Duniter par défaut. Pour ça il pourrait y avoir plusieurs nœuds par défaut, choisis au hasard à chaque exécution.
Ok alors je pense supprimer la nécessité d’attribuer une issue, car une contribution doit pouvoir se faire sans avoir à demander des droits
Tu as raison et si tu veux faire une MR pour ça je la mergerai.
L’idée est plutôt que l’utilisateur choisisse son noeud de référence au lancement de la commande. Il y a déjà une option -s qui le permet
Je n’ai pas l’ambition de faire de ğcli un client p2p, ça me semble un peu overkill pour un client en ligne de commande . Mais si quelqu’un veut faire ça ok
Sans aller aussi loin que Sakia, juste en essayer plusieurs jusqu’à ce que ça marche. J’ai déjà tout ce qu’il faut dans ĞMixer pour ça (ça ajoute une boucle dans le client et un itérateur shuffle). J’ai toujours la flemme d’utiliser Silkaj à cause de ça, du coup je vais sur Cesium mais il ne gère pas ça très bien donc il faut attendre 30 secondes qu’il propose un autre nœud Cesium+…
Non car personne ne l’a demandé. C’est rapide à faire, si tu en à besoin je peut implémenter la génération du mnemonic et du dewif. Le code Rust existe déjà, faut juste le «plugger» à ğcli
@poka je viens de faire ça à l’arrache, regarde dans le README.
Pour l’instant gcli n’a pas de release, pour l’installer faut cloner le dépôt git puis compiler avec la commande cargo build --release. Le binaire final nommé gcli se trouve alors dans target/release
Il est désormais possible de faire un paiement simple avec ğcli :
$ gcli balance 5txe6XBBJQ6WaQS82upPT6FmM2mc5JcBW97dAjyMpwq6
The server responded in 181 ms.
The balance of account 'SIG(5txe6XBBJQ6WaQS82upPT6FmM2mc5JcBW97dAjyMpwq6)' is 2.86 Ğ1 !
$ gcli wallet pay 3 -a 100 -r Do99s6wQR2JLfhirPdpAERSjNbmjjECzGxHNJMiNKT3P -c "from gcli"
Mnemonic:
Sending 1.0 Ğ1 to Do99s6wQR2JLfhirPdpAERSjNbmjjECzGxHNJMiNKT3P from transparent account 5txe6XBBJQ6WaQS82upPT6FmM2mc5JcBW97dAjyMpwq6 …
Payment succesfully processed in 242.734 ms.
Je crois qu’il s’agit du premier paiement réalisé depuis un HD wallet
ğcli ne supporte que les HD wallet, vous devez d’abord en générer un avec la commande gci wallet gen.
Ensuite, récupérez une clé publique d’un sous-compte transparent avec la commande gci wallet pubkey. puis envoyez des sous sur ce sous-compte transparent via un autre client Ğ1.
Enfin, réalisez votre paiement avec la commande gci wallet pay.
Prochaine étape, les paiements depuis un compte opaque/brouillé, ça va être une autre paire de manches
Je précise que ğcli est compatible DEWIF et qu’un HD wallet créé dans ğcli pourra être importé dans ğecko (et vice versa) via le mnemonic.
Est-ce que la commande gcli wallet pay est documenté ? à quoi correspondent les arguments ?
Là, je lis (sûrement de travers) que la commande est de payer 3 Ğ1 depuis un compte qui en présente 2.86
ou bien de payer 100 centimes de Junes ce qui fait bien un virement de 1 Ğ1 ? mais alors c’est quoi ce 3 ?
En fait le 3 ici correspond au numéro de dérivation de ton HD wallet.
On a choisi comme protocole d’utiliser les modulo 3 pour les dérivations “transparentes” des HD wallets (3,6,9,12, ect…).
Je pense qu’on détaillera cela avec Elois dans un poste à part.
: