Je me sens obligé de demander/proposer cette fonctionnalité avant d’aller plus loin.
Si j’ai bien compris, nous évitons les calls automatiques dans duniter pour s’assurer de pouvoir taxer quelqu’un si ce call échoue, et ainsi éviter le spam.
Mais ne serait-il pas possible de créer un nouvel extrinsic distance.requestDistanceEvaluationThenValidate(idtyIndex)
, qui ferait la même chose requestDistanceEvaluation
, mais qui programmerait également l’extrinsic validateIdentity
grâce au call schedule
en root (car appelable uniquement via root), à la condition que distance.identityDistanceStatus(idtyIndex)
soit validé ?
Ou bien, que cet extrinsic validateIdentity
soit appelé par l’oracle directement au moment de la publication si l’identité a le status confirmedByOwner
, étant donné que cet extrinsic est appelable par n’importe qui ?
Ainsi en cas d’échec, c’est celui qui appelle requestDistanceEvaluationThenValidate
qui trinque pour tout.
Je sais que techniquement c’est possible, mais les questions sont:
- Est-ce idiomatique de substrate et son oracle ?
- Si oui pensez-vous pouvoir implémenter ça pour le prochain runtime ?
Je préfère demander maintenant pour m’assurer de ne pas rentrer dans des mécaniques de validation d’identité côté client qui deviendraient obsolète avant même la mise en prod.
Dans l’hypothèse ou ceci n’est que fantaisie, le seul élément bloquant pour moi côté client reste que requestDistanceEvaluation
ne soit pas appelable pour n’importe qui (requestDistanceEvaluation(idtyIndex)
), de manière à la batcher avec la certification numéro minCertForMembership
(élément qui sera probablement renommé vue que vous avez décidé de faire sauter la palette membership
^^).