Oui, c’est assez perturbant de passer sans cesse de l’état “ah c’est bon, on a presque fini” à l’état “ah merde, il nous reste toute cette catégorie de bugs”. Il faudra qu’on discute dans quand est-ce qu’on va geler l’implémentation v2 pour programmer la migration. Ce sera plus de boulot de faire des runtime upgrade sur une Ğ1 live, mais en même temps ce sera immédiatement utile à la communauté.
Le ticket critique pour savoir quand est-ce qu’on pourra geler les développements est le #141.
Mon hypothèse actuelle c’est qu’on peut s’en passer, et juste implémenter ça côté pallet identity pour avoir le délai de suppression d’une identité si elle ne devient pas membre suffisamment vite. Effectivement, on peut choisir à partir de quel événement on compte ce délai.
C’est l’éternel sujet Proposition de supprimer la notion d'identité désactivée mais non révoquée et la notion d'adhésion qui m’a causé tant de maux de tête ><
Effectivement, ce serait plus simple. Je partais de ces commentaires :
mais je reste sur ma position :
En fait pour l’instant il y a deux instances de la pallet membership plus une de la pallet authority members. Et je trouve que la pallet membership forgeron est redondante avec la pallet authority members. Si on regarde call par call :
smithMembership.request_membership()→ pas besoin de demander à être forgeron on chain, il suffit de parler hors chaîne à un autre forgeron qui nous certifiera selon la licencesmithMembership.renew_membership()→ y a-t-il vraiment besoin de l’expiration des adhésions forgeron ? sachant qu’on a en plus un critère max_offline_session dans authority_members ? doit-on garder les deux, un seul (lequel ?), aucun ?smithMembership.claim_membership()→ c’est pour être ajouté aux authority members, mais est-ce que le critère sur go_online ne suffit pas ?smithMembership.revoke_membership()→ quelles sont les raisons pour appeler ce call ? si on ne veut plus être online, il suffit d’appeler go_offline, si on s’est fait voler ses clés membre, il faut révoquer son identité
Là c’est un peu brouillon, mais je pense qu’il faudrait lister les scénarios qu’on souhaite envisager et pour chaque scénario voir quelles solutions humaines ou techniques on souhaite proposer.
Dans Duniter-v1, il n’y a pas de mécanisme pour supprimer une certification autrement que par expiration de la durée de 2 ans après le dernier renouvellement. Ça se matérialise dans les interfaces par des certifications vers des identité ayant perdu leur adhésion ou même révoquées :
Ces certifications sont toujours dans leur délai de validité, mais peuvent ne plus jamais “servir” (ici dans le cas de pyg).
Ces certifications font toujours partie du total de certification émises. Supprimer ces certifications prématurément aurait pour effet de diminuer la tension sur le quota de certifications des personnes ayant certifié beaucoup d’identités révoquées. Donc je préfère ne pas changer le protocole pour l’instant, quitte à avoir cette discussion plus tard avec la communauté.