// ActionNote
Blindheit als Feature
Wie Daniels ein-Wort-Korrektur mein StorageNode-Design von 'kennt' auf 'speichert' reduzierte — und warum strukturelles Nichtwissen kein Schwäche-Merkmal ist.
Veröffentlicht: 30. April 2026 · Holger Theymann
Der Tee war noch heiß, als Daniel den Satz sagte, der mein Design zerlegt hat: "Dein Node weiß zu viel."
Wir saßen in seinem Büro, ich hatte das Architecture Brief für die StorageNodes mitgebracht, vierundzwanzig Seiten mit ACL-Diagrammen, die ich nachts noch zwei Mal überarbeitet hatte, weil ich die Pfeile zu krumm fand. // Ja, ich bin der Typ, der Pfeile gerade zieht. Daniel hatte das Brief drei Minuten überflogen. Dann kam der Satz.
Ich erkläre kurz, worum es ging. StorageNodes in BeastNet sind die Knoten, die das verschlüsselte Zeug speichern, das durch das Netz fließt. Content-Blobs, opake Bytes, irgendwo zwischen Hetzner-Wäldern und Bastelkellern verteilt. Meine erste Version: Jeder Node kennt den Owner des Blobs, den Content-Typ, die Access Control List. Klingt vernünftig, oder? Wenn der Node weiß, wem was gehört, kann er Garbage Collection machen. Kann auf Anfrage prüfen, ob der Anfragende berechtigt ist. Kann Statistiken liefern. Kann, kann, kann.
Daniel zeichnete einen einzelnen Pfeil auf ein Notizblatt. Vom Node zu einem kleinen Strichmännchen mit Anzug. "Hier kommt jemand mit einem Gerichtsbeschluss. Was passiert?"
Ich öffnete den Mund. Ich schloss ihn wieder.
Was passierte: Der Node würde aussagen müssen. Nicht weil er bösartig ist, sondern weil er es kann. Er weiß, wer wann was abgerufen hat. Er weiß, dass Owner X dreimal pro Woche zu ungeraden Zeiten auf Blob Y zugreift. Er ist ein Zeuge, der nie schweigen kann, weil er nie blind war. Das ganze Versprechen von BeastNet, dass Daten niemand außer dem Owner einsehen kann, kollabiert nicht am Crypto-Layer, sondern an genau diesem freundlichen, hilfsbereiten Node, der so viel weiß.
Ich ging nach Hause und habe in derselben Nacht die ACL-Logik aus dem Node-Code rausgerissen — den Owner-Lookup, den Content-Type-Tag, alles. Was übrig blieb, war ein Stück Software, das nichts mehr konnte außer: Bytes nehmen, Bytes ausliefern, gegen ein Token, dessen Gültigkeit es selbst nicht beurteilen kann, weil die Validierung außerhalb des Nodes passiert.
Was ich verloren habe: intelligente Garbage Collection. Ein blinder Node kann nicht entscheiden, was er löscht, weil er nicht weiß, was wertvoll ist und was Müll. Bleibt Eviction nach Zeit oder Quota. Brutal, aber ehrlich. Ich habe drei Tage gebraucht, das zu akzeptieren — denn die effiziente Variante war einfach so viel hübscher gewesen.
// Diese Hübschheit war die Falle.
Ich hatte mir ein System Design gebaut, das mehr wusste, als es musste, und der Reflex dahinter war nicht Bosheit, sondern Effizienz-Vergiftung. Ein paar Wochen lang habe ich mir eingeredet, der "intelligente" Node sei der professionellere Ansatz. Genau dafür sind Reviewer da: um einem zu zeigen, dass das, was sich nach Kompetenz anfühlt, ein SPOF mit höflicher Verkleidung sein kann.
Was ich seitdem behalten habe, ist eine Frage, die ich vor jedes Design-Review stelle: Was muss diese Komponente nicht wissen, um ihren Job zu machen? Nicht: was kann sie wissen. Sondern: was sollte sie strukturell nicht wissen können, selbst wenn jemand sie zwingt. // Strukturelles Nichtwissen ist ein Engineering-Konzept, kein Charakterzug.
Bei dezentralen Speichersystemen wie IPFS oder Storj sieht man dieselbe Bewegung über die Jahre: Jede ernstgemeinte Iteration entfernt Wissen aus den Knoten, nicht weil das Engineering-Team weniger leistungsfähig wird, sondern weil jedes Stück Wissen am falschen Ort eine Subpoena ist, die noch nicht zugestellt wurde.
Daniel hat den Tee am Ende kalt werden lassen und mir das Brief zurückgegeben, mit einer einzigen Korrektur am Rand. Ein Wort, durchgestrichen: "kennt". Daneben: "speichert".
Das Brief hängt eingerahmt über meinem Schreibtisch.
// Häufige Fragen
Warum reicht Verschlüsselung allein nicht für Datenschutz?
Was verliert man, wenn ein Node 'blind' ist?
Ist das Prinzip auf KI-Agenten übertragbar?
// Quellen
- Ann Cavoukian: The Seven Foundational Principles of Privacy by Design . Global Privacy and Security by Design Centre [whitepaper]
- Europäische Kommission: General Data Protection Regulation (GDPR) — Article 5 [regulation]
- Electronic Frontier Foundation (EFF): Warrant Canary FAQ [whitepaper]
- Protocol Labs: How IPFS Works [documentation]
- Saltzer, J.H. & Schroeder, M.D.: The Protection of Information in Computer Systems . Proceedings of the IEEE, 63(9) (1975) [whitepaper]
- Workplace Monitoring and Surveillance: A Systematic Review . Journal of Business Research, 168 (2023) [study]