Oui, en effet, dans Duniter-v2 une paire de clés n’identifie pas une identité de manière unique. On pourrait ajouter un mécanisme qui permet de bannir des clés. Et on pourrait bannir les anciennes clés lorsque l’on appelle change_owner_key. Mais c’est un nouveau mécanisme à ajouter côté Duniter alors que pour moi ça pourrait se régler côté client. Il faudrait détailler ce scénario d’attaque dans un post dédié pour voir si c’est pertinent d’y apporter une solution côté Duniter.
Oui, la SOC c’est de la convenance. On pourrait avoir un architecture monolithique, mais elle serait plus compliquée à comprendre et faire évoluer. Alors que là c’est très clair : pallet identity pour gérer l’identité, pallet membership pour gérer l’adhésion. Une identité peut avoir un historique d’obtention et expiration d’adhésion.
Attention, je vais avoir des réticences à approuver des modifications qui diminuent la modularité du logiciel. C’était le cas pour ta branche qui intégrait le calcul de la distance directement dans la pallet certification, j’étais réticent à cette idée.
J’ai ouvert ce fil pour réfléchir à retirer les pending membership (demandes d’adhésions), pas les membership (adhésions), que je souhaite conserver.
Un exemple d’utilisation de l’historique d’adhésion : afficher le DU dans l’historique des transactions. C’est d’ailleurs en réfléchissant à implémenter ça côté indexeur que je me suis rendu compte que seuls les événements MembershipAcquired et MembershipExpired étaient utiles, pas Pending*. J’ai donc fait une pause dans l’implémentation de duniter-squid pour aborder ce sujet ici, éventuellement aboutir au retrait des pending_machinchose (donc simplifier), puis reprendre l’implémentation côté indexeur pour arriver à fournir simplement l’historique des DU perçus.