ĞDev -- j'ai perdu mon identité

Ce qui devait arriver arriva : je n’ai pas été attentif à mon nombre de certifications reçues sur la ĞDev et ai perdu mon statut de membre au bloc 1521978.

  • ancien identity index : 2457
  • nombre de certifications avant ce bloc : 5 32
  • perte d’une certification
  • perte du statut de membre
  • retrait de l’identité

On en revient une fois de plus à ce sujet : Proposition de supprimer la notion d'identité désactivée mais non révoquée et la notion d'adhésion

Maintenant, si je veux déclarer une nouvelle identité, je dois repartir de zéro certifications, et donc demander à quelqu’un de me créer une identité, la confirmer en utilisant un autre pseudo, puisque le mien est toujours réservé, obtenir quatre autres certifications, puis refaire la demande pour être forgeron… bref tout le parcours depuis zéro. Je peux cependant utiliser la même clé il me semble.

Je vais faire un récap des options possibles, avantages et inconvénients. Je lancerai un vote et implémenterai le résultat. Ce changement peut valoir le coup, mais ça constitue un gros changement par rapport à la v1 et il n’y a aucune urgence à le faire maintenant. En attendant, pas de DUĞDev pour moi :joy_cat:


problème : cert.storageIdtyCertMeta(2457) retourne toujours

{
  issuedCount: 57
  nextIssuableOn: 1,477,238
  receivedCount: 32
}

Il faudrait tester la cohérence entre les métadonnées de certifications et le nombre de certifications réellement actives.


Poka m’a créé une nouvelle identité, son identity index est 7238, elle n’est pas encore membre.

1 Like

En attendant tu peux te remettre membre avec sudo, en mettant un bloc d’expiration très lointain.

Si j’ai bien suivi, les solutions sont :

  • (actuellement) révocation
  • statut non-membre temporaire

Pour l’instant le seul moyen de supprimer les usernames des identités expirées est l’extrinsic root prune_item_identities_names. Peut-être qu’il devrait aussi expirer, par exemple un an après l’expiration de l’identité, mais qu’il pourrait être repris par une nouvelle identité appartenant à la même clé que l’ancienne.

Je viens de recréer ton identité.

Mais c’est bizarre que tu ai perdu toutes tes certifications, tu en avait 33 encore la semaine dernière, car ce sont celle de ton réseau Ğ1

1 Like

Oui, tu as raison, je me suis planté dans le screenshot que je t’ai envoyé par Matrix, j’avais bien 32 certifications, le problème n’est pas le manque de certifications. Je me suis planté dans mon diagnostic parce que je me suis planté de identity index. Je continue à chercher.

[edit] bon, mon premier diagnostic a planté parce que j’essayais de travailler sur un coin de table, le deuxième parce que j’essaye de travailler dans le train. J’arrive pas à bien bosser, je vais juste attendre de pouvoir me poser pour regarder ça au calme parce que je comprends plus rien.

1 Like

Très compliqué à débugger. On a bien ces résultats là :

image

Pour la requête

identity.identityIndexOf(5Dq8xjvkmbz7q4g2LbZgyExD26VSCutfEc6n4W4AfQeVHZqz) aux blocs

  • 1521977 (0x747b271204f81f23353cd4a2a19f5de3d29bbeb90835f12ce54dc27fe2883bd8)
  • 1521978 (0x27f71a5bfb6dab8c2e54dc35c4ddf5df65e189ca92e6bddbf2418b41d8e3a5eb)

Mais l’identité qui est marquée comme expirée à ce bloc est la n°2453, donc pas la 2457.

J’abandonne pour aujourd’hui. Si @tuxmain tu veux investiguer, fais-toi plaisir :smiley:

Le seul endroit où une identité est supprimée automatiquement est prune_identities, qui cherche les identités à supprimer dans IdentitiesRemovableOn, or il n’y a aucune entrée dans cette map aux blocs concernés.

Donc soit c’est un affreux bug très bizarre, soit c’est juste une révocation manuelle.

La 2457 est toujours membre… Mais qui était 2453 ?

Edit: on pourrait ajouter un champ “raison” à l’événement RemovedIdentity, pour savoir si c’est automatique ou manuel. Ou ajouter des événements IdentityExpired, IdentityLostCerts, IdentityManuallyRevoked.

Re-edit: Non c’est bien un “system event”, pas un “extrinsic event” donc ce n’est pas une révocation manuelle. Alors je ne comprends pas comment l’identité a pu être supprimée.

1 Like

Il y a un bug pour sûr, l’état du storage est corrompu:

identitiy.identities(2457): (anciennement Hugo)

image

2457:
ownerKey: 5Dq8xjvkmbz7q4g2LbZgyExD26VSCutfEc6n4W4AfQeVHZqz

identity.identityIndexOf("5Dq8xjvkmbz7q4g2LbZgyExD26VSCutfEc6n4W4AfQeVHZqz"):

image

7238:
5Dq8xjvkmbz7q4g2LbZgyExD26VSCutfEc6n4W4AfQeVHZqz

L’adresse de hugo a donc désormais 2 identityIndex en fonction de comment on le regarde :slight_smile:


Et bien, au bloc 0x27f71a5bfb6dab8c2e54dc35c4ddf5df65e189ca92e6bddbf2418b41d8e3a5eb, c’est aussi Hugo !

Ca fait donc 3 idtyIndex pour hugo !

Il s’est passé quelque chose de très palpitant à ce bloc :slight_smile:

1 Like

Soit le genesis a fait un truc bizarre, soit on a fait une bêtise en root/sudo, soit on a un gros gros bug.

Il faudrait compléter les live tests.

2 Likes

Cette erreur était présente dès le genesis, cf Sanity tests - #6 by HugoTrentesaux.
Il faudra penser à lancer les sanity tests sur le genesis de la prochaine itération pour éviter de reproduire ces problèmes.
On pourrait soumettre un proposal pour réparer les incohérences du storage (ou le faire en sudo). Il faudrait :

  • supprimer les entrées 3595 et 2457 des identités avec system.killStorage()
  • mapper les addresses 5DUjwHRqPayt3tAZk1fqEgU99xZB9jzBHKy2sMSTNcc7m9D1 et 5Dq8xjvkmbz7q4g2LbZgyExD26VSCutfEc6n4W4AfQeVHZqz sur les index 3594 et 2453 à la place avec system.setStorage()