J’ai aussi de quoi faire tourner un nœud Smith pour rendre le réseau de test plus stable, il ne me manque plus que les certifications
5F6xAX1k6eRKUGrF7exifKcS2K2SB781Cn6soV1kahjwkGpg.
Fait :
gcli smith cert 14154 929ms Mon Dec 4 12:30:32 2023
transaction submitted to the network, waiting 6 seconds...
certified as smith NewCert { issuer: 34, issuer_issued_count: 8, receiver: 14154, receiver_received_count: 1 }
(no event of type gcli::runtime_config::runtime::smith_cert::events::RenewedCert)
Tiens, c’est intéressant, ça, on peut aussi émettre des certifications forgeron vers une identité qui n’est pas validée (et on n’a toujours pas d’oracle de distance intégré aux noeuds pour valider les identités). Décidément cette toile de forgeron n’arrêtera pas de me surprendre ! (c’est pas tant un bug qu’une discussion à avoir sur les spécifications)
Je t’avoue que je n’ai même pas vérifié si bgallois était membre ou pas, j’ai vu qu’il parlait directement de la toile smith et j’ai supposé qu’il était membre.
Surprenant, en effet ! Je suis plutôt opposé au fait de pouvoir insérer des données en toile forgeron pour quelqu’un qui n’est pas membre.
Ça fait partie du check que je voulais ajouter : une certification (forgeron ou pas) ne devrait pouvoir être ajoutée que s’il y a une demande d’adhésion ou une adhésion en cours à la toile correspondante. C’est ce dont je parlais dans ce sujet : Pallets instanciables et vérifications d'adhésion. Et comme la demande d’adhésion ne peut être faite que si l’identité est membre, ce serait bon.
Mais si on compare, en Duniter v1 on pouvait signer une certification à n’importe quel moment, c’est juste qu’elle n’était incluse en blockchain qu’à la validation, elle restait en piscine entre temps. Dans Duniter v2 on pourrait décider de découpler totalement et d’autoriser les certifications vers des identités sans critère supplémentaire. Reste à en discuter