Ok, du coup je vais builder une image depuis la branche master pour l’utiliser pour le service distance-oracle dans la stack docker compose.
La question qui me reste est: est-ce que cette image faite à partir de master peut également être utilisée pour les noeuds duniter (mirror, archive, smith) ou est-ce que pour ceux là je continue à garder mon image faite à partir de la branche network/gdev-800 ?
Cette commande devrait te permettre de faire ta « demande d’adhésion » avec tes identifiants v1 :
gcli -S cesium identity request-distance-evaluation
L’authentification v1 n’est pas compatible avec la v2. Pour celà, il faut migrer son compte vers une autre adresse qui utilise l’authentification avec mnémonique. C’est possible avec gcli change-owner-key.
Oui, bien sûr ! Pour utiliser le correctif de tuxmain, il y a un correctif sur l’oracle et un autre sur le client. Donc, à utiliser sur ton oracle et ton nœud smith (et autres si tu le souhaites) pour que le correctif ait effet.
Je ne suis pas sûr pour cette commande…
Si je teste l’impact the “-s cesium” il semble ne rien faire; et garde l’adresse publique actuelle dans la configuration:
# Sans paramètre, retourne l'adresse de ma nouvelle identity "Nicolas80-GDev"
gcli config show
Ğcli config
duniter endpoint wss://gdev.gyroi.de
indexer endpoint https://squid.gdev.gyroi.de/v1/graphql
address 5HE6gH87fVuGj6akXneNceBtgEiaUZua43TJbVBRQTT77gp6
# Juste avec le paramètre "-s cesium" toujours la même identity
gcli -s cesium config show
Ğcli config
duniter endpoint wss://gdev.gyroi.de
indexer endpoint https://squid.gdev.gyroi.de/v1/graphql
address 5HE6gH87fVuGj6akXneNceBtgEiaUZua43TJbVBRQTT77gp6
# Alors que si on prend par exemple les paramètres pour Alice
gcli -S predefined -s Alice config show
Ğcli config
duniter endpoint wss://gdev.gyroi.de
indexer endpoint https://squid.gdev.gyroi.de/v1/graphql
address 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
# L'adresse est bien adaptée par celle d'Alice...
Donc je pense que si j’exécute la commande plus haut dans l’état actuel de mon GCli, il va effectuer la demande request-distance-evaluation pour ma nouvelle identity (address 5HE6gH87fVuGj6akXneNceBtgEiaUZua43TJbVBRQTT77gp6)
Ah… dans l’aide GCli, je vois que c’est pour le paramètre “-S” pour le format du secret, que l’on peut préciser “cesium” (en plus de “seed” ou “susbtrate”).
C’est déjà plus clair 
Par contre, je ne trouve pas quelle valeur donner à -s pour le secret quand on est avec -S cesium
gcli -S cesium -s "<valeursSecretCesium>" config show
Error: Logic("cesium format incompatible with single secret")
Edit: Ok, j’ai compris après avoir été regardé le code source GCli 
On ne doit donner que le -S cesium et surtout pas le secret (-s) car GCli va demander l’id et le password Cesium en prompt:
gcli -S cesium config show
Cesium id:
Cesium password:
Ğcli config
duniter endpoint wss://gdev.gyroi.de
indexer endpoint https://squid.gdev.gyroi.de/v1/graphql
address 5GhAZBagx87sTGfMppfPPcWhxCKGWE8zDi1oHp7YiKosD9KZ
→ C’est bien mon ancienne identité G1v1
Bien vu, c’est -S cesium
Je tente de comparer les branches origin/network/gdev-800 et master avant de refaire un build; et j’ai peur que dans les 2 cas il manque des commits qui ne sont pas dans l’autre branche…
origin/network/gdev-800 et pas dans master9d84097 (2024-11-07 16:19:51 +0100) - (HEAD -> network/gdev-800, tag: gdev-803, origin/network/gdev-803, origin/network/gdev-800)update srtool [Hugo Trentesaux]
97a3149 (2024-11-07 14:04:10 +0100) - increase distance evaluation period [Hugo Trentesaux]
be05224 (2024-11-07 13:58:57 +0100) - update srtool version in doc [Hugo Trentesaux]
20408a1 (2024-11-07 13:58:43 +0100) - runtime 803 [Hugo Trentesaux]
05e6475 (2024-10-11 16:45:40 +0200) - fix lockfile [Hugo Trentesaux]
007e22e (2024-10-11 16:44:31 +0200) - update client specs [Hugo Trentesaux]
master et pas dans origin/network/gdev-800f73a957 (2024-11-22 17:07:28 +0100) - (origin/master, origin/HEAD)Fix distance evaluation client (nodes/rust/duniter-v2s!291) [Pascal Engélibert]
3811164 (2024-11-18 11:07:35 +0100) - add protobuf-compiler package to documentation (nodes/rust/duniter-v2s!289) [Nicolas80]
1ea5bce (2024-11-15 10:37:49 +0100) - (master)Upgrade polkadot v1.16.2 (nodes/rust/duniter-v2s!288) [Benjamin Gallois]
f7d8319 (2024-11-13 15:44:32 +0100) - Deprecate Currency trait (nodes/rust/duniter-v2s!287) [Benjamin Gallois]
449c176 (2024-11-13 13:47:33 +0100) - distance-oracle: fix docs and cli help [Pascal Engélibert]
f290f3c (2024-11-13 13:47:33 +0100) - node: fix distance-oracle cli [Pascal Engélibert]
25bdd2d (2024-11-13 13:47:33 +0100) - doc: distance-oracle interval [Pascal Engélibert]
147bccb (2024-11-13 13:47:33 +0100) - dc-client: remove unused deps [Pascal Engélibert]
ea62918 (2024-11-13 13:47:33 +0100) - distance-oracle: sheduler [Pascal Engélibert]
bcc0a50 (2024-11-13 12:40:44 +0100) - Refactore Runtime handlers and providers (nodes/rust/duniter-v2s!286) [Benjamin Gallois]
Du coup @HugoTrentesaux, @Moul, @tuxmain est-ce que c’est certain que je peux builder et utiliser master partout ?
Sinon je peux créer une branche locale à partir de origin/network/gdev-800 et cherry-pick juste le commit du “Fix distance evaluation client” - ou bien tenter de rebase avec 'master`… mais comme je ne connais pas le projet; je risque de faire pire que mieux 
Il n’y a que Nicolas qui puisse le faire ?
En attendant, c’est impossible de le certifier ?
Apparemment, je ne peux pas le faire sur duniter portal ni avec gecko…
Manque-t-il des fonctionnalités ?
J’ai ajouté une certification depuis mon nouveau compte(7 certifications en tout maintenant), mais je ne sais pas si c’est suffisant que pour demander une réévaluation de la distance de mon compte G1v1 ?
Tout membre peut demander l’évaluation pour une autre identité.
Si l’identité existe, on peut la certifier, et il vaut mieux le faire avant l’évaluation puisque ça donnera une meilleure qualité de distance.
Je fais tout avec PolkadotJS et DuniterConnect, ça marche.
Oui, en tout cas c’est ce que je fais sans Docker.
Pour utiliser le compte v1 on peut le faire dans DuniterConnect.
[edit]
Tant qu’il y a une personne bien centrale dans la TdC parmi les certificateurs (comme les devs), il ne devrait pas y avoir de problème à satisfaire la règle de distance.
Oui. Il y a trois livrables : le client, le runtime et l’oracle.
Le client et l’oracle sont à utiliser de master par exemple. Le runtime est généré via une branche network/XXX et est intégré via une fonction Substrate.
Ça ne fonctionne pas :
gcli identity request-distance-evaluation-for Nicolas80
Enter password to unlock account 5HDikVWZ2xHfqvVVFwex5zmRsH4LuR3KqMgKZYEbCSjStSKw
Password:
transaction submitted to the network, waiting 6 seconds...
Pallet error: Distance::TargetMustBeUnvalidated
Dans les messages ci-dessous, je vois qu’il faut que je précise quelques concepts.
Un binaire contient plusieurs choses :
--chainSur la branche master, tu auras tout sauf les chainspecs embarquées, qui permettent de se connecter à un réseau sans avoir à fournir des chainspecs à part (par exemple via un fichier *_raw.json).
Mais si tu ne supprimes pas les données du nœud existant, il n’y a pas besoin des chainspecs (le genesis et les pairs sont déjà connus dans le storage local), donc en théorie l’exécutable produit sur master pourrait convenir. Par contre, il ne permet pas de rejoindre le réseau tel quel. Pour ça, il faut donner l’argument --chain. Avec docker c’est via DUNITER_CHAIN_NAME en montant les raw chainspecs dans le volume.
L’oracle est disponible comme sous-commande du nœud (qui inclut aussi le client). Le runtime est un livrable particulier, puisqu’en étant connecté à un réseau (donc en connaissant le runtime au genesis et des pairs), on récupère les versions successives du runtime en synchronisant la blockchain. Cela se fait lorsque l’on récupère un bloc qui contient un runtime upgrade.
Les branches network/xxx sont surtout là pour publier des nouvelles versions du client. C’est parce que #239 n’est pas encore fait que je crée une branche network pour les nouveaux runtimes, mais normalement il devrait suffire d’un commit depuis master.
Dans le cas d’une identité qui a déjà été membre (pas pour une nouvelle identité), la demande d’évaluation de distance est synonyme de renouvellement d’adhésion. Donc seul l’identité peut la faire. Par contre, il est évidemment possible de le certifier : c’est la seule manière pour qu’il puisse atteindre à nouveau le seuil de certification s’il est passé dessous, ou pour qu’il puisse respecter la règle de distance.
Oui pour une nouvelle identité, non pour une identité qui a déjà été membre, car c’est synonyme de renouvellement d’adhésion.
Heureusement, sinon ça signifierait qu’on pourrait renouveler l’adhésion de quelqu’un d’autre. C’est juste possible pour une nouvelle identité pour faciliter le parcours membre (suite à cette demande : Demande d'améliorations pour la pallet distance - #8 by poka).
Je n’ai pas vu cette possibilité dans duniterportal, ni dans gecko, est-ce que ces fonctionnalités sont prévues @poka
Dans Duniter Panel, il y avait un bug lié au nouvel affichage des certifications, merci de me l’avoir fait remarquer.
Dans Ğecko, c’est un bug qu’on peut voir à la ligne 356 : lib/providers/substrate_sdk.dart · master · clients / Ğecko · GitLab. @poka quand quelqu’un n’est pas membre, on peut quand même le certifier pour qu’il redevienne membre.
2 posts were split to a new topic: Trouver des meilleurs noms pour les applis
Je viens de tenter la demande d’évaluation de distance pour l’ancien compte:
gcli identity get -a 5GhAZBagx87sTGfMppfPPcWhxCKGWE8zDi1oHp7YiKosD9KZ
Identity index: 12242
Username: Nicolas80
Address: 5GhAZBagx87sTGfMppfPPcWhxCKGWE8zDi1oHp7YiKosD9KZ
Status: NotMember
Certifications: received 7, issued 4
gcli -S cesium identity request-distance-evaluation
Cesium id:
Cesium password:
transaction submitted to the network, waiting 6 seconds...
evaluation requested EvaluationRequested { idty_index: 12242, who: AccountId32([204, 191, 164, 196, 40, 253, 29, 55, 210, 195, 173, 73, 89, 40, 69, 106, 27, 229, 111, 230, 59, 182, 242, 55, 38, 221, 56, 131, 140, 8, 141, 251]) }
Par contre, est-ce que comme peu de serveurs SMITHS ont l’oracle de distance; j’aurais du me connecter sur un serveur en particulier dans mon GCli (ou cela ne change rien) ?
J’ai créé une image à partir de master et l’ai utilisée pour mes noeuds:
Ca semble bien fonctionner vu que j’ai gardé les volumes dockers qui avaient été initialisés avec l’image basée sur network/gdev-800.
Par contre, dans telemetry je vois que ces 2 noeuds sont maintenant renseignés comme implementation 0.8.0 au lieu de 0.8.1 avant.
Est-ce que l’on ne devrait pas maintenir à jour la branche de network/gdev-xxx actuelle avec les changements utiles depuis master (comme ça il ne faut pas jongler avec les images si on veut déployer un nouveau noeud).
Ou peut-être que c’est simple de jouer avec l’argument --chain; mais comme je ne connais pas trop les détails du projet; à priori je trouve plus simple une image complète avec le moins d’opérations manuelles supplémentaires
Il y a une confusion ici sur la nature d’une blockchain. Quand tu soumets ta demande auprès d’un nœud miroir :
elle sera diffusée sur le réseau (en moins de deux secondes), puis intégrée par un nœud forgeron dans un bloc (en moins de deux secondes), puis ce bloc sera diffusé à tous les nœuds (en moins de deux secondes). Le résultat est que peu importe à quel nœud tu soumets ta transaction, tu la verras apparaître dans un bloc en six secondes en moyenne.
Ta demande est bien présente dans le bloc 4070548.
Ensuite, c’est aux nœuds forgeron de publier le résultat obtenu par leur oracle de distance. Et c’est là que ça foire puisqu’on n’a pas fini de corriger le bug.
De mon côté je vois bien l’oracle qui produit une évaluation :
hugo@trentesaux:~/docker/duniter-gdev-smith/distance-oracle$ docker compose logs --tail 100 -f
[...]
INFO [distance_oracle] Distance for idty 12242: 815/987 = 82.573456%
[...]
mais mon nœud forgeron n’a rien publié parce que mon oracle produit les fichiers nommés “1”, “2”, “3” là où mon nœud forgeron s’attend à trouver les fichiers avec un numéro de session.
Ensuite le nœud de @tuxmain fait tourner une version différente de l’oracle, mais je ne sais pas s’il a mis à jour son nœud forgeron également, en tout cas il n’a pas publié d’évaluation donc ça ne marche pas encore comme il l’a dit :
Effectivement c’est le programme pour la suite :
master dans network/gdev-800 (c’est moi qui m’en occuperai)Pour résumer, c’est en cours. Pour aider tu dois d’abord finir le parcours forgeron (passer online) et te tenir prêt à installer la 0.9.0. Si tu veux aller encore plus vite, tu peux essayer de compiler la branche fix-262 en avant-première et la tester sur la gdev pour produire l’évaluation de distance nécessaire pour que ton identité Nicolas80 passe membre.
Pour ce qui est de ton identité Nicolas80-GDev, elle est passée membre au bloc 4030700 parce @joss.rendall avait publié une évaluation correcte :
évaluation visible au bloc 4030699
Donc merci JosselinFERREIRA d’être le meilleur forgeron ! Meilleur que tuxmain et moi qui avons essayé d’être en avance sur les développements mais avons installé une version cassée. Meilleur que moul et cgeek aussi dont les oracles de distances semblent silencieux 
.
Je plaisante, il n’y a pas de “meilleur” forgeron, juste des versions avec des bugs différents et une seule personne qui est passée à travers les gouttes 
4 posts were merged into an existing topic: Alpha test de Duniter 0.9.0
A post was merged into an existing topic: Champ “expose” du docker compose
c’est la méthode “Egyptien” , marcher de côté pour éviter les gouttes 
