Je propose cette discussion en français pour trancher sur ce que nous devons implémenter sur la Ğ1v2 à son lancement, on pourra toujours changer plus tard au moment opportun. Ma proposition n’est pas entièrement spécifiée, j’attends que les spécifications ressortent des échanges. Fixer l’implémentation faciliterait le lancement d’une ğtest : Rewrite genesis parsing for ĞTest.
Le retrait de l’identité du storage entraîne les conséquences suivantes :
perte définitive de l’identité et de ce qui y est rattaché (certifications en cours, identité forgeron…)
impossibilité de reprendre le même pseudo (il est réservé)
Scénario actuel
Actuellement tel qu’implémenté dans Duniter v2s, voici les cas possibles de retrait d’une identité du storage :
identité créée mais non confirmée après le délai de confirmation (24h)
identité confirmée mais non validée après le délai de validation (2 mois)
révocation manuelle d’une identité
expiration de l’adhésion (passage sous le seuil des 5 certifs, réévaluation de la règle de distance) (cf code, @tuxmain tu avais oublié ceci)
Avantages / Inconvénients :
dans le cas de la perte des identifiants, l’utilisateur peut recréer une identité dès la suppression de l’ancienne identité car impossible qu’elle redevienne membre
si utilisateur inactif ou inattentif, nécessité de reprendre de zéro le processus de création d’identité, et de changer de pseudo (mais les anciens identifiants pourront être utilisés)
Scénario proposé
Je propose de modifier ce comportement pour coller plus près au fonctionnement actuel et être moins punitif.
à l’expiration de l’adhésion, l’identité reste dans le storage et n’est pas modifiée, il n’y a juste plus d’adhésion associée. On peut parler d’identité “désactivée” ou “inactive”, mais c’est juste qu’elle n’est pas comptée comme membre de la toile de confiance, elle ne génère plus de DU, ne peut plus certifier…
à l’expiration de l’adhésion, la suppression de l’identité est programmée pour un délai donné (par exemple 2 mois), cela laisse assez de temps pour réagir (recevoir les certifications manquantes ou respecter à nouveau la règle de distance
Avantages / Inconvénients :
cela laisse un délai à l’utilisateur inattentif pour récupérer son identité en gardant les certifications qu’il lui reste et le pseudo
cela impose un délai supplémentaire à quelqu’un ayant oublié ses identifiants pour être en droit de créer une autre identité (en pratique rien ne l’en empêche)
Observation
Ce choix revient à attribuer une origine à l’inactivité d’un membre parmi (1.) la perte d’identifiants ou (2.) la perte d’activité sociale (décès ou désintérêt par exemple). La perte d’identifiant est une raison technique qui pourra être mitigée par le sharding par exemple. La perte d’activité est une raison humaine non liée à la blockchain.
Une complication qui me vient à l’esprit pour les identités désactivées :
ça va complexifier le calcul du DU. Ça doit être tout de même faisable en versant les DU non réclamés lors de la désactivation (comme lors de la suppression).
Oui, le versement manuel des DU c’est juste pour éviter de le faire à chaque DU, mais on peut très bien le faire à chaque changement lié à l’identité, ça me paraît très bien comme ça. (pour les autres, cf UdsAutoPaidAtRemoval).
Je vois qu’il n’y a plus le besoin de renouveler annuellement l’adhésion pour prouver que nous sommes vivant. C’est une charge mentale de moins pour l’utilisateur (et la principale cause de perte temporaire de DU me semble-t-il).
Je cherche des cas où cela entraînerait la production illicite de DU au profit d’une personne autre que la personne certifiée.
Si ce sont les certifications seules qui font survivre un compte, alors il peut y avoir un cas où la personne est décédée mais son compte reste actif par ces certificateurs qui renouvelleraient par habitude.
C’est un cas marginal, mais peut-être une fenêtre de fraude exploitable. Je pose ça là.
(Je pose beaucoup de choses là en ce moment… Désolé… )
Effectivement, comme dit @vit, ni le scénario actuel, ni le scénario proposé n’incluent un arrêt de production du DU en cas de décès. Ce que rappelle @Moul est une proposition de @elois qui n’a pas été implémentée.
Mon post se concentre sur les conséquences de la perte d’adhésion, mais pas sur ses causes. Voici donc la liste des causes possibles :
causes de l’expiration de l’adhésion
passage sous le seuil des 5 certifs
réévaluation négative de la règle de distance
Et cela, dans les deux scénarios (à la fois l’implémentation actuelle et dans le scénario proposé).
Il faudrait donc ajouter une cause de la perte d’adhésion : inactivité sur le compte. On a plusieurs possibilités pour compter l’activité :
intégrer la modification de ce compteur à chaque action sur le compte (ça me semble un peu crade)
ajouter un extrinsic pour repousser la date d’expiration (renouvellement d’adhésion), cet extrinsic pouvant éventuellement être appelé automatiquement par les clients dans un batch call, sous les conditions souhaitées (approche de l’expiration, à chaque transaction…)
et plusieurs possibilités pour déclencher l’expiration :
expiration automatique gérée par la blockchain avec une liste d’identités à expirer par bloc donné
expiration manuelle avec un extrinsic qui échoue si la date d’expiration n’est pas passée (possibilité de laisser active une identité expirée si personne / aucun bot ne décide de la faire expirer)
J’ai une préférence pour la première solution qui est plus homogène avec les autres implémentations d’expirations (certification…)
D’ailleurs pour l’instant j’ai l’impression que le renouvellement d’identité n’est jamais fait : on ne bouge jamais une identité dans IdentitiesRemovableOn. (les identités post-genesis vont donc forcément expirer)
Je suis pour la solution de l’extrinsic de renouvellement. Ça réduit les coûts en blockchain (sinon tout extrinsic causerait une lecture db des identités).
Je voulais dire qu’on n’augmente jamais le bloc d’expiration d’une identité, donc c’est pas juste une proposition pas implémentée mais une fonctionnalité manquante.
On n’augmente pas le bloc, mais on teste si l’identité peut vraiment être retirée, si elle n’a pas changé de statut on ne la retire pas. Donc oui, pas de retrait d’identité. C’est à faire.
dans le cas de la perte des identifiants, l’utilisateur peut recréer une identité dès la suppression de l’ancienne identité car impossible qu’elle redevienne membre
si utilisateur inactif ou inattentif, nécessité de reprendre de zéro le processus de création d’identité, et de changer de pseudo (mais les anciens identifiants pourront être utilisés)
)