Merci, il me manque 2 certifs avant de faire la demande forgeron. Merci de votre aide.
En attendant qu’on mette en place des oracles sur le réseau, j’ai utilisé les pouvoirs de sudo pour la distance de @bgallois :
Et en bonus comme tout le monde peut le faire :
gcli identity validate 14154
transaction submitted to the network, waiting 6 seconds...
identity validated IdtyValidated { idty_index: 14154 }
[edit] aussi fait pour Daigongen
Donc il nous faut des certifications de forgerons (@vit @1000i100 ou @tuxmain) à destination de @poka @bgallois et @daigongen.
[edit 2] @moul et @Pini, vous ne voulez plus être forgerons ?
1 Like
Si, je veux toujours. Mais je ne pourrais m’y mettre que dans un moins au plus tôt.
Ça prend du temps à intégrer tout ce nouvel écosystème avec le peu de temps que j’arrive à y dédier.
J’aimerais aussi pouvoir le faire via Silkaj. J’utiliserais Ğcli en attendant.
Si si. Mais j’attends que ma semaine de purgatoire soit terminée pour pouvoir à nouveau migrer mon identité vers la bonne clef. Dimanche soir normalement.
Aux apprentis forgerons docker sur la gdev8, c’est le moment d’installer un oracle de distance : Oracle de distance dans un docker - #10 by HugoTrentesaux. C’est un peu plus technique et optionnel, donc ne vous sentez pas obligés, mais c’est important quand même et ça permet d’apprendre des choses donc n’hésitez pas, vous ne risquez rien 
2 Likes
Je viens de mettre à jour mon serveur et d’installer Duniter. 
Comment puis-je redevenir smith, il faut être invité ?
D’ailleurs je ne sais pas trop pourquoi je suis exclu. Il a été mentionné un délai de 3 semaines mais je ne sais pas pourquoi ce délai.
Aussi, docs/user/smith ne semble pas à jour. N’oubliez pas de maintenir la doc à jour dans vos MR !
1 Like
L’exclusion a été mentionnée ici : Runtime 801 - #9 by HugoTrentesaux. Je te réinvite :
$ gcli identity get -u tuxmain
Identity index: 1401
Username: tuxmain
Address: 5D6aqdN9m5uhAsJycKPQra6WqaaxzVb6BptgiY5HsrPkAotL
Status: Member
Certifications: issued 16, received 12
Smith status: Excluded
Smith certs: issued 6, received 6
$ gcli smith invite tuxmain
Enter password to unlock account 5Dq8xjvkmbz7q4g2LbZgyExD26VSCutfEc6n4W4AfQeVHZqz
Password:
transaction submitted to the network, waiting 6 seconds...
sent smith invitation InvitationSent { receiver: 1401, issuer: 344 }
$ gcli identity get -u tuxmain
Identity index: 1401
Username: tuxmain
Address: 5D6aqdN9m5uhAsJycKPQra6WqaaxzVb6BptgiY5HsrPkAotL
Status: Member
Certifications: issued 16, received 12
Smith status: Invited
Smith certs: issued 6, received 6
tu n’as plus qu’à faire gcli smith accept, recevoir deux certifications, et go_online.
Bien vu pour la doc, sinon il y a une autre doc ici : Duniter | Become smith (pas encore choisi laquelle maintenir, ça me parait plus simple de faire sur le site, mais si on fait sur le dépôt, on peut facilement l’inclure sur le site de manière automatique).
1 Like
Merci ! Encore quelques trucs à faire sur mon serveur et je go online avec l’oracle.
Puisque plusieurs versions de Duniter cohabitent (versions de dev pour les contributeurs, version pour la gdev, futures versions pour gtest et g1), le plus simple et sûr pour assurer la cohérence entre le code et la doc pour tout le monde est de maintenir la doc du dépôt à jour de manière atomique.
Les changements de doc peuvent aussi servir lors de la relecture de MR.
Le site pourrait n’afficher que la doc de la dernière release (je ne sais pas si c’est simple à automatiser) (et comment gérer entre releases runtime et client, je ne sais pas).
1 Like
Je n’avais pas relevé, mais c’est un bug, ça. Normalement un forgeron exclu perd ses certifications reçues, non ? Ou alors c’est un bug d’indexeur.
À diagnostiquer…
[edit] c’est un bug d’indexeur, @poka l’a corrigé en local, il publiera ça prochainement
Je ne compte pas versionner la doc sur le site. Juste afficher une seule version à destination des forgerons, donc en accord avec le réseau live.
1 Like
D’ailleurs pourquoi supprimer les certifications reçues lors de l’exclusion pour inactivité ? Ça, combiné à l’expiration en 3 semaines, me semble suffisant à rendre difficile le maintien de la toile forgeron. Si quelqu’un a un problème de serveur ou part en vacances 1 mois, il faut récupérer toutes les certifs.
AuthorityMembers est déjà là pour régler le problème de l’inactivité.
1 Like
Identity index: 1401
Username: tuxmain
Address: 5D6aqdN9m5uhAsJycKPQra6WqaaxzVb6BptgiY5HsrPkAotL
Status: Member
Certifications: issued 16, received 12
Smith status: Pending
Smith certs: issued 6, received 6
@tuxmain est en pending pour Smith, besoin d’une nouvelle certif ou faut patienter un cycle pour que son go-online soit pris en compte ?
1 Like
Oui j’aurais besoin de certifs forgeron. Le received 6 que tu vois doit être le bug d’indexeur mentionné ci-dessus (d’ailleurs c’est bizarre que gcli utilise l’indexeur pour ça). Dans PolkadotJS j’ai ça :
[
[
1,401
]
{
status: Pending
expiresOn: 969
issuedCerts: [
34
49
344
12,949
]
receivedCerts: [
344
]
}
]
1 Like
Hop, certifié et il t’en suffit de deux pour la ĞDev.
receivedCerts: [
34
344
]
Et pour te répondre :
J’avais documenté cela dans la MR!217 :
Peut-être que le délai de 3 semaines est trop court. Par contre je ne vois pas de raison à laisser traîner des Smith trop longtemps non plus, ne serait-ce que pour des raisons de sécurité (si le Smith délaisse son nœud et que sa clé finit par être dérobée par exemple).
À la base j’avais suggéré 2j, @HugoTrentesaux a préféré mettre un délai large pour la ĞDev.
edit : par contre la perte du statut Smith ne provoque pas la perte des certifications émises, donc l’argument que ce paramètre rendrait difficile le maintien ne me semble pas valable. Tu peux relire la doc de la MR, je pense avoir tout expliqué.
2 Likes
Ok je pensais que les certifs forgeron avaient une durée de validité. Je suis toujours un peu gêné par le contraste entre la très courte durée pour la mesure d’activité et la validité infinie des certifications.
Ce n’était pas justement la raison d’obliger à changer souvent ses session keys, et qui avait été considérée assez négligeable pour supprimer cette obligation ? Est-ce que la durée de 3 semaines sert à remplacer cela ?
1 Like
transaction submitted to the network, waiting 6 seconds…
new smith certification SmithCertAdded { receiver: 1401, issuer: 12950 }
ben une de plus quand même !!!
Identity index: 1401
Username: tuxmain
Address: 5D6aqdN9m5uhAsJycKPQra6WqaaxzVb6BptgiY5HsrPkAotL
Status: Member
Certifications: issued 16, received 12
Smith status: Smith
Smith certs: issued 6, received 7
2 Likes
Je ne trouve pas que 3 semaines soit une durée courte pour un forgeron, qui justement devrait afficher une bonne réactivité et être contactable au besoin. En plus la toile Smith est beaucoup plus restreinte et resserrée, ce devrait être simple de récupérer ses certifications suite à une perte (et on voit bien que c’est le cas).
Pour moi 2j c’était déjà suffisant, peut-être un peu trop court.
Ce n’est pas tellement pour remplacer l’ancienne règle de rotation des session keys. C’est plus pour encourager la proactivité et décourager le délaissement.
1 Like
On peut ajuster le délai ou revoir les règles. À discuter encore, maintenant c’est géré dans smith-members. Moi ça me gène pas de laisser ce sujet de côté un moment pour avancer sur les autres aspects de la migration et d’y revenir avec plus d’exemples en situation réelle de la part des autres “apprentis forgerons”.
Corrigé dans la MR !17 qu’il me reste à relire.
Oui, j’ai ajouté ça dans une refac d’indexeur, mais ce serait mieux de faire directement depuis Duniter. Le but était d’avoir les noms quand même quand on fait -o json, mais il faudrait le faire d’après les idtyindex de rpc.
1 Like