#newt $NEWT @NewtonProtocol #Newt
je pensais que les politiques de protocole étaient essentiellement des recueils de règles statiques. Les téléverser une fois, les auditer une fois, et c’est terminé. Plus j’en apprends sur le protocole Newton, plus je me rends compte que cette hypothèse était loin d’être exacte.
Ce qui a attiré mon attention, c’est la façon dont Newton sépare la logique de politique Rego réutilisable de la configuration dynamique associée à un PolicyClient. Au lieu de réécrire le code de politique pour chaque cas d’utilisation, la même logique peut être réutilisée tandis que des paramètres comme les seuils, les limites d’exposition et les listes d’autorisation approuvées sont transmis via data.params sous forme de JSON plat.
Cela m’a rappelé quelque chose de simple dans la vie réelle. Ma famille utilise les mêmes règles de maison pour tout le monde, mais mon jeune cousin a des limites différentes des miennes au même âge. Les règles ne changeaient pas. La configuration, oui. Le principe restait cohérent tandis que les limites s’adaptaient.
Newton suit une philosophie similaire, mais avec des garanties beaucoup plus solides. Un détail que j’ai trouvé particulièrement intéressant est expireAfter. Il définit la fenêtre du bloc d’exécution pour une attestation, pas le moment où les paramètres eux-mêmes expirent. Si on le règle trop court, des exécutions valides peuvent échouer parce que la fenêtre se referme trop vite. Si on le règle trop long, l’opportunité de relecture ou d’exécution différée augmente. Aucun des deux choix n’est automatiquement correct. Le contexte compte.
Un autre choix de conception subtil est que la mise à jour des paramètres via setPolicy(PolicyConfig) crée un tout nouvel identifiant de politique (policyId). La configuration précédente devient immédiatement obsolète, créant une frontière claire entre les états de politique anciens et nouveaux plutôt que de modifier silencieusement les hypothèses de confiance.
Mon enseignement le plus important n’était pas la flexibilité. C’était la responsabilité. Rego définit la logique, mais ce sont les personnes qui définissent les paramètres, les passent en revue et, au final, façonnent le résultat.
Alors, où les évaluateurs devraient-ils consacrer le plus d’attention : au code de politique réutilisable, ou aux paramètres cachés dans data.params ? Cette architecture rend-elle les règles réutilisables en toute sécurité, ou bien déplace-t-elle les hypothèses de confiance les plus importantes vers des configurations que de nombreux utilisateurs ne consulteront pas ?
je pensais que les politiques de protocole étaient essentiellement des recueils de règles statiques. Les téléverser une fois, les auditer une fois, et c’est terminé. Plus j’en apprends sur le protocole Newton, plus je me rends compte que cette hypothèse était loin d’être exacte.
Ce qui a attiré mon attention, c’est la façon dont Newton sépare la logique de politique Rego réutilisable de la configuration dynamique associée à un PolicyClient. Au lieu de réécrire le code de politique pour chaque cas d’utilisation, la même logique peut être réutilisée tandis que des paramètres comme les seuils, les limites d’exposition et les listes d’autorisation approuvées sont transmis via data.params sous forme de JSON plat.
Cela m’a rappelé quelque chose de simple dans la vie réelle. Ma famille utilise les mêmes règles de maison pour tout le monde, mais mon jeune cousin a des limites différentes des miennes au même âge. Les règles ne changeaient pas. La configuration, oui. Le principe restait cohérent tandis que les limites s’adaptaient.
Newton suit une philosophie similaire, mais avec des garanties beaucoup plus solides. Un détail que j’ai trouvé particulièrement intéressant est expireAfter. Il définit la fenêtre du bloc d’exécution pour une attestation, pas le moment où les paramètres eux-mêmes expirent. Si on le règle trop court, des exécutions valides peuvent échouer parce que la fenêtre se referme trop vite. Si on le règle trop long, l’opportunité de relecture ou d’exécution différée augmente. Aucun des deux choix n’est automatiquement correct. Le contexte compte.
Un autre choix de conception subtil est que la mise à jour des paramètres via setPolicy(PolicyConfig) crée un tout nouvel identifiant de politique (policyId). La configuration précédente devient immédiatement obsolète, créant une frontière claire entre les états de politique anciens et nouveaux plutôt que de modifier silencieusement les hypothèses de confiance.
Mon enseignement le plus important n’était pas la flexibilité. C’était la responsabilité. Rego définit la logique, mais ce sont les personnes qui définissent les paramètres, les passent en revue et, au final, façonnent le résultat.
Alors, où les évaluateurs devraient-ils consacrer le plus d’attention : au code de politique réutilisable, ou aux paramètres cachés dans data.params ? Cette architecture rend-elle les règles réutilisables en toute sécurité, ou bien déplace-t-elle les hypothèses de confiance les plus importantes vers des configurations que de nombreux utilisateurs ne consulteront pas ?