Je suis assis avec quelque chose d'inconfortable concernant l'architecture de Sign depuis quelques jours et je n'arrive pas à m'en défaire.
Le crochet s'exécute une fois. C'est tout. L'entrée arrive, la logique du crochet évalue quelles que soient les conditions que l'auteur du schéma a intégrées, et l'une des deux choses se produit.
L'entrée devient une attestation ou elle disparaît. Il n'y a pas d'état intermédiaire. Aucun enregistrement visible de la tentative. Pas de trace de ce qui s'est approché mais n'a pas réussi. Le protocole continue simplement en étant impeccable.
Et je comprends pourquoi c'est conçu de cette façon. Des surfaces de preuves claires sont tout l'enjeu. Vous ne voulez pas que des revendications rejetées à moitié formées encombrent SignScan aux côtés des attestations valides. Cela a du sens techniquement.
Ce qui me dérange, c'est ce que ce design fait aux personnes qui lisent la sortie plus tard.
Quand je regarde une attestation résolue sur Sign, je vois la chose qui a survécu. Je ne vois pas les trois entrées qui ont été exécutées avant elle et ont échoué.
Je ne vois pas si le crochet qui a passé celui-ci était exceptionnellement permissif ce jour-là, ou si un changement de configuration a modifié le seuil d'admissibilité entre le lot d'hier et celui d'aujourd'hui. L'attestation semble exactement la même indépendamment de tout ce contexte.
Le crochet est écrit par l'auteur du schéma, pas par Sign. Donc, lorsque quelque chose est rejeté et disparaît, le protocole est véritablement propre.
Sign n'a pas fait d'erreur. Le crochet de l'auteur du schéma a pris une décision et cette décision s'est produite quelque part que la couche d'attestation ne touche jamais.
Ce qui signifie que si je suis en aval et que j'essaie de comprendre si cette approbation signifie ce que je pense qu'elle signifie, je lis la sortie d'un portail que je ne peux pas voir, écrit par une partie que je ne pourrais pas comprendre entièrement, qui a été exécuté une fois et n'a laissé aucun enregistrement visible de ce qu'elle a considéré.
Ensuite, il y a la situation de extraData. C'est la partie à laquelle je reviens sans cesse. Les champs qui portent le contexte de politique, l'ère du programme à laquelle cette attestation appartient, les conditions spécifiques qui ont rendu cette revendication valide sous cette version de schéma particulière, celles-ci voyagent techniquement avec l'attestation. Elles sont là.
Mais la plupart des systèmes en aval, TokenTable, intégrations partenaires, filtres d'éligibilité, vérifient la correspondance du schéma et la validité de l'attestation, puis avancent. Personne n'ouvre extraData. C'est trop de travail pour un portail binaire oui-non.
Ainsi, l'attestation voyage. Elle est portable. Elle traverse les chaînes, est consommée par différents systèmes, apparaît dans les distributions six mois plus tard.
Et elle porte le contexte complet du moment et des raisons pour lesquelles elle était valide à l'intérieur d'un champ que les systèmes qui agissent dessus ne lisent jamais.
Je ne pense pas que ce soit un échec de Sign. Je pense que c'est le coût honnête de rendre des preuves portables à grande échelle. Vous ne pouvez pas faire en sorte que chaque système en aval reconstruise le contexte de décision complet chaque fois qu'il touche un enregistrement. Cela casserait tout.
Mais cela signifie que la couche d'attestation fait moins de travail qu'il n'y paraît. La véritable décision s'est produite au niveau du crochet. Le crochet a été exécuté une fois de manière invisible.
L'enregistrement qui est sorti de l'autre côté semble autoritaire, réglé et complet.
Et il voyage de cette façon pour toujours, que les conditions qui l'ont rendu valide s'appliquent encore ou non. @SignOfficial $SIGN
