Ich erinnere mich daran, wie ich mir das frühe @NewtonProtocol Newton-Material angesehen habe und davon ausging, dass die Policy-Schicht nur eine reine Compliance-Funktion sei — also eine Möglichkeit, Ausgabenlimits und Sanktionsprüfungen an eine Transaktion zu heften, bevor sie freigegeben wird. Das ist der Pitch, der am häufigsten wiederholt wird. Aber wenn man länger darüber nachdenkt, fiel nicht die Prüfung selbst ins Gewicht, sondern die Einrahmung rund um die Wiederverwendung. Sie nennen es immer wieder ein „Internet der Policies“ — die Idee, dass eine einmal geschriebene Regel, zum Beispiel eine Sicherheiten-Grenze oder ein Risikolimit, nicht in der App gefangen bleibt, die sie geschrieben hat. Sie wird veröffentlicht, referenziert und in andere Systeme zusammengesetzt, so wie eine API von Fremden aufgerufen wird, die sie nie selbst gebaut haben.#Newt

Das ist eine andere Art von System als ein Compliance-Tool. Ein Compliance-Tool löst ein Problem für ein einzelnes Unternehmen. Ein Policy-Marktplatz ergibt nur dann Sinn, wenn tatsächlich andere Entwickler auftauchen und Regeln abrufen, statt ihre eigenen von Grund auf zu schreiben. Daher ist die eigentliche Frage nicht, ob der Durchsetzungsmechanismus funktioniert — Audits werden dir das irgendwann ohnehin bestätigen. Entscheidend ist, ob es überhaupt Nachfrage nach geteilten Policies gibt, oder ob jedes Team weiterhin lieber seine eigene Logik schreibt, weil es ein härteres Problem ist, der Regel eines anderen zu vertrauen, als Code zu schreiben.

Niemand übernimmt gemeinsame Infrastruktur nur, weil sie elegant ist. Man übernimmt sie, wenn die eigenen Kosten für das Schreiben der Version mehr sind als das Ausleihen der Version von jemand anderem.

Was ich als Nächstes beobachte, ist nicht die Roadmap. Es ist die Frage, ob eine Policy, die von einem Projekt gebaut wurde, still und unverändert in den Stack von jemand anderem auftaucht.
$YFI $PYTH
#newt $NEWT