Indexeurs : que faire au retrait d'une certification ? au renouvellement?

Il y a un cas qu’on n’a pas traité pour l’instant dans les indexeurs : l’expiration d’une certification.
On pourrait tout simplement retirer la certification de l’indexeur si le but est de garder l’état au moment actuel, mais vu que l’intérêt de l’indexeur est également d’avoir un historique, on pourrait juste marquer la certification comme expirée.

Donc on pourrait compléter les champs de Cert :

type Cert {
 issuer: Identity!
 receiver: Identity!
 createdOn: Int!
 expireOn: Int!
}

et juste regarder si expireOn est avant ou après le bloc courant. Si on fait ça, que faire dans le cas du renouvellement d’une certification ? Si l’idée est de garder un historique, on pourrait ajouter un autre type :

type CertRenewal {
  cert: Cert!
  createdOn: Int!
}

et mettre à jour la date d’expiration de la certification initiale. Comme ça, pour une certification, on pourrait accéder à l’historique de ses renouvellements.

Ce serait plus pratique à utiliser que la version actuelle de l’indexeur dans laquelle une nouvelle entrée est créée pour chaque renouvellement de certification, ce qui fait qu’on doit réaliser un traitement côté client pour ne pas afficher de certification en double (la certification et son renouvellement).

Et dans ce cas par symétrie, il faut ajouter :

type CertRemoval {
  cert: Cert!
  deletedOn: Int!
}

Tu peux aussi avoir deux tables : une pour l’état courant, et une pour l’historique pour séparer les problématiques.

1 Like

Donc ça veut dire qu’on peut identifier deux besoins et y répondre séparément pour simplifier le problème :

  1. connaître l’état actuel
    • quelles sont les certifications actuelles valides émises / reçues
    • quelles sont les certifications actuelles expirées émises / reçues
  2. connaître l’historique
    • quel est l’historique des certifications et renouvellements pour une certification donnée

Par exemple pour l’état actuel on pourrait faire les requêtes :

    • certifications émises / reçues par A où expired est false
    • certifications émises / reçues par A où expired est true
    • liste des créations, renouvellements, expirations associés à un couple issuer / receiver A → B

Donc ça penche plutôt vers l’option 1 proposée dans Squid pour Duniter, épisode 2. Mais ça ne change pas le fait qu’on peut changer le id.


Il faut quand même avoir un champ expireOn pour connaître la date d’expiration programmée pour une certification.

Tout en se rappelant que c’est la blockchain qui décide quand interviendra réellement l’expiration, et donc qu’il faut attendre un évènement RemovedCert pour faire expirer la certification.

1 Like

Dans ce cas on pourrait l’appeler “shouldExpireOn”

1 Like