Note: je ne trouve plus les discussions relatives au fait d’émettre une demande d’adhésion en même temps que la cinquième certification. Il y a ce post, mais c’est un peu éloigné.
J’ai émis la cinquième certification avec Silkaj v0.20. Je m’attendais à ce que le certifié fasse une demande d’adhésion comme en v1. Du coup, la situation semble un peu bloquée et non souhaitée.
Je trouve qu’on ne devrait pas cacher des fonctionnalités de manière non-transparentes pour l’utilisateur. L’utilisateur devrait pouvoir demander son adhésion par une action volontaire. Ça pose un problème de workflow entre les apps.
À priori Cesium v2 et Ğecko implémentent ce workflow. Qu’en est-il des autres apps ?
Que pensez-vous de ce workflow et de la situation produite entre les deux workflow ?
Si quelqu’un trouve la discussion à ce sujet, je veux bien qu’on déplace cette discussion dans celle historique.
Le déclenchement de l’évaluation de la règle de distance devrait être une action externe à la blockchain pour permettre d’éviter que la blockchain mesure en boucle des distances qui ne remplissent pas le critère (éviter les calculs inutiles).
Une évaluation positive de la règle de distance devrait aboutir immédiatement à la validation de l’adhésion / au renouvellement de l’adhésion pour ne pas avoir à conserver l’évaluation pendant une durée indéterminée et demander une action externe pendant ce laps de temps (simplification du processus d’adhésion).
Par conséquent, enclencher une évaluation de distance est synonyme de “adhérer” / “ré-adhérer”.
Un nouveau membre a déjà exprimé sa volonté de rejoindre la toile (= adhérer) auprès du premier membre qui a créé son identité et des autres membres qui l’ont certifié, il ne devrait pas avoir besoin de renouveler ce souhait (simplification du processus d’adhésion). Par conséquent, la première certification permettant l’entrée dans la toile (nombre de certifications reçues + distance) devrait déclencher l’évaluation de la règle de distance.
Comme il n’y a pas moyen côté blockchain de savoir le résultat de l’évaluation avant la réponse des oracles, cette action doit être déclenchée côté client (il a pu faire le calcul lui même).
Mais comme c’est une fonctionnalité côté client, il est possible que le client ne l’implémente pas, l’implémente sans en avertir l’utilisateur, l’implémente mal (fasse la demande alors que le résultat de l’évaluation sera négatif)…
Je suis d’accord, il serait bien de l’implémenter de manière transparente, par exemple en calculant localement la règle de distance et en proposant à l’utilisateur de joindre une demande d’évaluation à sa certification si l’évaluation est positive. Il faudrait également expliquer à l’utilisateur le coût de la sanction si les oracles trouvent un résultat différent du résultat local.
Actuellement il faut inspecter les piscines des demandes d’évaluation dans le storage onchain. Mais ce serait bien plus pratique d’ajouter cette fonctionnalité à squid. Ça pourrait être fait en indexant les événements EvaluationRequested, EvaluatedValid, EvaluatedInvalid (cf #17). Désolé, je n’ai jamais réussi à m’y remettre.
Si les apps envoient une demande alors qu’il y en a déjà une en cours, l’extrinsic échouera avec AlreadyInEvaluation (cf Duniter | Runtime errors).
Merci du rappel ! Tikka pouvait toujours attendre, aucune chance après une certification que l’identité passe membre sans envoyer cette demande d’évaluation.
Quelqu’un aurait-il déjà développé un calcul local de distance pour une seule identité ? @tuxmain@poka ou @deepseek ?
En attendant, je vais déjà implémenter la commande réseau RPC dans l’API sortante de Tikka. Ca va, j’ai un mois…
Le calcul en lui-même n’est pas compliqué. Le plus coûteux est de charger les données (listes des identités et des certifications). Je ne suis pas sûr que ce soit une bonne idée d’encourager les clients à télécharger tout ça, surtout qu’avec les blocs de 6s la mise en cache risque d’être peu efficace.
