DaWN-Dokumentation · Lantern
Die Tür im Netz
Ein Netz aus Knoten auf Endgeräten hat ein Verfügbarkeitsproblem: Rechner werden abends ausgeschaltet. Gehostete Websites laufen rund um die Uhr, über viele Domains und Rechtsräume gestreut, und es gibt Millionen davon. Der naheliegende Gedanke, sie als Netzknoten zu verwenden, scheitert an einer harten Eigenschaft ihrer Laufzeit — und genau daraus folgt der Zuschnitt aller Rollen.
Reifegrad dieser Seite
Die Erweiterung selbst ist gebaute, laufende Software mit rund tausend Klassen. Ihre Netzrollen sind es nicht: Die zuständige Klasse wirft durchgehend „nicht implementiert". Was hier zu den Rollen steht, ist Festlegung, nicht Code. Wo etwas läuft, steht es ausdrücklich dabei.
Problem 1
Eine Website ist kein Knoten — und kann trotzdem einer sein
Ein Prozess des Redaktionssystems lebt nur während einer einzelnen Anfrage, also Sekunden. Weiterleitung im Sinne von Zwiebelrouting verlangt dauerhaft lauschende, sofort weiterleitende Verbindungen über Stunden. Dieser Unterschied ist kategorischer Natur und nicht wegzuoptimieren. Statt ihn zu ignorieren, ist er zum Entwurfskriterium gemacht: Jede vorgesehene Rolle muss innerhalb einer Anfrage vollständig erledigt sein.
| Rolle | Was sie tut | Warum sie passt |
|---|---|---|
| Einstiegspunkt | Liefert die aktuellen Adressen eines zugeordneten Knotens aus — Datenbank lesen, JSON schreiben, fertig. | Eine Abfrage, eine Antwort. Kein Zustand über die Anfrage hinaus. |
| Identitäts-Beobachter | Hält den letzten gültigen Stand einer Identitätsdatei vor und liefert ihn aus — auch wenn die ursprüngliche Domain längst weg ist. | Vorhalten heisst hier speichern, nicht verbinden. Das Ausliefern ist wieder eine Anfrage. |
| Zeitgeber | Beteiligt sich rundenweise am Verfahren, aus dem der Zufallswert für das Zeugen-Losverfahren entsteht. | Rundenbasiert, nicht echtzeitkritisch — eine Runde ist eine Handvoll Anfragen. |
| Nicht vorgesehen: Weiterleitung | Dauerverbindungen halten und Pakete durchreichen. | Braucht einen eigenen Dauerprozess. Den installiert die Erweiterung bewusst nicht mit. |
Durchgespielt
Jemand installiert die Erweiterung — und wird zum Netzeinstieg
- Installation. Eine gewöhnliche Website-Erweiterung, aus demselben Beweggrund installiert wie jede andere: Schutz vor Spam, Beobachtbarkeit, Auffindbarkeit.
- Verknüpfung. Die Betreiberin hinterlegt die Kennung ihres eigenen Knotens. Dafür genügen Schreibrechte in der Datenbank; ein Zugriff auf die Namensverwaltung ist nicht nötig.
- Ein Fremder sucht einen Einstieg. Seine Anwendung fragt einen festen Pfad auf der Domain ab und bekommt Knotenkennung und Adressen als schlichte Antwort.
- Verbindung. Er spricht den genannten Knoten direkt an. Die Website war nur der Wegweiser und ist ab jetzt aus dem Spiel.
- Nebeneffekt. Jede Website mit dieser Erweiterung ist damit ein Einstieg — ohne dass jemand bewusst Infrastruktur betreibt.
Was das nicht leistet: Wer in die Datenbank der Website schreiben kann, lenkt Einsteiger auf fremde Adressen — eine zusätzliche Signatur ist für die erste Auslieferung nicht vorgesehen. Weil die Knotenkennung selbst ein Schlüssel ist, scheitert die Verbindung zum falschen Ziel aber am Handshake: ein Verfügbarkeitsproblem, keine Übernahme.
Problem 2
Woran man erkennt, dass eine Erweiterung unverändert ist
Das Redaktionssystem bringt keinen Integritätsschutz mit: Wer eine Datei austauscht, merkt es niemand. Die Antwort ist ein signiertes Verzeichnis aller ausgelieferten Dateien, das der Kern vor dem Registrieren prüft und später im Gesundheitscheck wiederholt — offline, ohne Rückfrage bei einem Lizenzdienst. Ein Fehlschlag bricht dabei nie den Betrieb ab, sondern meldet.
Die Grenze, die daneben steht
Innerhalb einer Installation gibt es keine Prozesstrennung. Gegen eine bereits installierte bösartige Erweiterung mit vollen Rechten hilft kein Prüfmechanismus, weil dann auch der Prüfcode selbst veränderbar wäre. Das Modell wirkt gegen manipulierte Pakete und stille Dateiveränderung — nicht gegen einen Angreifer, der schon schreiben darf. Diese Grenze steht ausdrücklich in der Architektur, statt verschwiegen zu werden.
Getragen wird das von einer Aufteilung in Kern und Funktionsteile, bei der der Kern keinen einzigen Modulnamen kennt und Geschwister sich nicht direkt ansprechen dürfen.
Problem 3
Formulare, die keine Menschen abweisen
Dieselbe Schutzlinie gilt an zwei Stellen — im Veröffentlichungs-Frontend und in der Website-Erweiterung, mit derselben Prüfmaschine im Hintergrund. Produktiv läuft sie bislang nur an der ersten. Ein Konflikt ist offen und benannt: Für die gemeinsame Linie gilt, dass der Server allein trägt; der ältere Eingang der Erweiterung verlässt sich aber auf Mitwirkung im Browser. Wer beide zusammenführt, muss das zuerst auflösen.