Der Bus: Wie Dokumente miteinander reden, wenn niemand dazwischensitzt

Der vorherige Beitrag hat dafür argumentiert, dass eine HTML-Datei mit eingebettetem LLM der richtige Ersatz für die Office-Suite ist. Dieses Argument funktionierte auf der Ebene eines einzelnen Dokuments. Interessant wird die Frage, was passiert, wenn Sie mehr als eines haben. Die Office-Suite hat das vor dreißig Jahren beantwortet, und die Antwort hieß Einbettung: Sie ziehen ein Excel-Diagramm in ein Word-Dokument, und Word greift in Excel hinein, um es darzustellen. OLE, dann COM, dann COM+, und vor all dem DDE: eine Folge von Protokollen, mit denen ein Dokument ein Stück eines anderen halten konnte. Jede Generation löste echte Probleme. Jede Generation brach auch an derselben Stelle: Die Verbindung setzte voraus, dass beide Anwendungen installiert waren, beide in der richtigen Version vorlagen und beide auf einem Rechner liefen, den die IT-Abteilung abgesegnet hatte. Was ich hier beschreiben möchte, ist von anderer Art. Dokumente betten einander nicht ein. Sie sitzen nebeneinander auf einem Bus.

Einbettung war vertikal. Der Bus ist horizontal.

OLE und seine Nachfolger waren um eine Hierarchie herum gebaut. Ein Containerdokument enthielt ein Kinddokument. Der Container wusste vom Kind, das Kind zeichnete sich in den Container hinein. Öffneten Sie den Container, ohne dass die Anwendung des Kindes installiert war, bekamen Sie einen Platzhalter. Die Beziehung war strukturell und asymmetrisch, und sie reiste mit der Datei.

Der Bus funktioniert anders. Es gibt keinen Container und kein Kind. Jedes Dokument ist ein gleichrangiger Peer. Dokumente kündigen sich auf einem gemeinsamen Kanal an und abonnieren die Ankündigungen, die sie interessieren. Ein Vertragsdokument enthält nicht das Budgetdokument. Der Vertrag veröffentlicht die Tatsache, dass es ihn gibt, was er ist und wen er betrifft. Das Budget hört die Ankündigung, falls es im selben Browser-Kontext geöffnet ist, und entscheidet, ob die Information nützlich ist. Keines der beiden Dokumente hält das andere. Keines braucht das andere, um dargestellt zu werden. Sie sind gleichzeitig da, aber nicht ineinander verschachtelt.

Das ist eine andere Protokollform. Einbettung beantwortet wie stellt Word ein Excel-Diagramm dar. Der Bus beantwortet woher weiß dieser Vertrag, dass in einem anderen Tab ein Budget für denselben Kunden offen ist.

Was der Bus konkret ist

Konkret besteht der Bus aus der Tatsache, dass zwei HTML-Dateien, die aus dem lokalen Dateisystem geöffnet werden, sich einen Origin teilen. Browser behandeln file://-URLs so, als teilten sie sich den Null-Origin. Ein BroadcastChannel, den ein Dokument öffnet, ist also von einem anderen Dokument aus erreichbar, das auf dieselbe Weise geöffnet wurde. In diesem Bild gibt es keinen Server. Es gibt kein Protokoll, das erst ausgerollt werden müsste. Der Bus existiert, weil die Dokumente zur selben Zeit auf demselben Rechner offen sind.

Jedes Dokument tritt beim Öffnen einem benannten Kanal bei und veröffentlicht ein kleines Manifest. Das Manifest ist ein JSON-Objekt. Es gibt die Art des Dokuments an (contract, budget, meeting-notes) und eine Handvoll Kennungen (den Kundennamen, ein Datum des Inkrafttretens, eine Referenznummer). Es veröffentlicht keinen Inhalt. Es veröffentlicht Metadaten. Der Inhalt bleibt im Dokument. Andere Dokumente auf dem Kanal empfangen das Manifest, und ihre Runtime speichert es. Wenn der Nutzer ⌘K aufruft, fügt die Runtime die relevanten Peer-Manifeste in den System-Prompt ein. Das LLM, das auf die Anweisung antwortet, weiß jetzt, dass in einem anderen Tab ein Vertrag für denselben Kunden offen ist. Den Text des Vertrags kennt es nicht, nur die Tatsache, dass es ihn gibt, und seine deklarierten Metadaten.

Das ist ein kleines Stück Infrastruktur. Es ist auch ein anderes Modell dafür, wie Dokumente zueinander stehen.

Wie Deklarationen aussehen

Das Manifest eines Dokuments sind die Daten, die das Dokument über sich selbst zu veröffentlichen bereit ist. Die Runtime stellt dafür eine API bereit, das Dokument füllt sie aus. Ein aus rwa veröffentlichter Vertrag könnte ankündigen:

{
  kind: "contract",
  client: "Acme Inc.",
  effective: "2026-01-01",
  parties: ["Acme Inc.", "Generic Corp"],
  reference: "INV-000/2026"
}

Ein Budget für denselben Kunden, aus einem anderen Tab veröffentlicht, könnte ankündigen:

{
  kind: "budget",
  client: "Acme Inc.",
  period: "2026-Q1"
}

Jedes Dokument ist die Autorität für sein eigenes Manifest. Keines der beiden Dokumente stellt Behauptungen über das andere auf. Ein Widerspruchsproblem gibt es nicht, weil es keine gemeinsame Überzeugung gibt. Es gibt gemeinsame Metadaten, und die Vereinigung der Manifeste ist das, was gerade zufällig auf dem Kanal ist.

Ein Dokument abonniert, indem es deklariert, was es interessiert: sag mir Bescheid bei Verträgen, sag mir alles zu Kunde X. Die Runtime filtert den Kanal und liefert die Treffer. Die Treffer fließen als Kontext in den nächsten Prompt ein. Der Nutzer kann das Budgetdokument fragen: welche Verträge gibt es für diesen Kunden, und das Dokument antwortet aus den Manifesten, die es gehört hat, nicht aus irgendeiner Datenbank.

Warum das kein zweites OLE ist

OLE setzte Dokumente auf der Ebene der Darstellung zusammen. Ein Diagramm erschien in einem Dokument, weil Word und Excel beide liefen, beide das Protokoll sprachen und eines in die Oberfläche des anderen zeichnete. Die Komposition war visuell, unmittelbar und eng gekoppelt.

Der Bus setzt Dokumente auf der Ebene des Wissens voneinander zusammen. Dokumente zeichnen nicht ineinander. Sie wissen voneinander. Die Komposition ist informationell, asynchron und lose. Ein Dokument auf dem Bus funktioniert weiter, auch wenn alle anderen Dokumente geschlossen sind. Sein Layout ändert sich nicht. Sein Inhalt ändert sich nicht. Das Einzige, was sich ändert: Das LLM hat beim nächsten ⌘K weniger Kontext aus dem Umfeld, auf den es zurückgreifen kann.

Das ist das Gegenteil des Fehlerbilds von OLE. Fehlte die verknüpfte Excel-Datei, zeigte das Word-Dokument einen kaputten Platzhalter. Verlässt ein Peer den Bus, hören die Dokumente, die gelauscht haben, einfach weniger. Es kann nichts brechen, weil nichts gehalten wird.

Die Vertrauensgrenze verschiebt sich

Die Einbettung der OLE-Zeit legte das Vertrauen in den Anwendungs-Stack. Vertraute Word Excel, führte es Excel-Makros aus, um das eingebettete Diagramm darzustellen. Die Vertrauensgrenze lag beim Installieren, auf Betriebssystemebene, vermittelt durch den Hersteller der Office-Suite.

Der Bus legt das Vertrauen in den Zuhörer. Jedes Dokument entscheidet, was es mit dem Gehörten macht. Ein Manifest, das auf dem Kanal ankommt, sind Daten, keine Anweisung. Die Runtime des Dokuments behandelt es als Eingabe für den Kontext des LLM, und deshalb muss das Dokument bewusst damit umgehen, was eingefügt wird und wie. Ein Manifest mit sorgfältig konstruiertem Text könnte ein Angriffsweg für Prompt Injection gegen jedes Dokument sein, das es aufnimmt. Die Runtime behandelt Peer-Manifeste wie jede andere nicht vertrauenswürdige Eingabe: strukturiert, gegen ein Schema geprüft, niemals ausgeführt, dem Nutzer niemals ohne Herkunftsangabe gezeigt.

Das ist eine echte Einschränkung, und über eine solche musste OLE nie nachdenken. Die Vertrauensprobleme von OLE drehten sich darum, ob die eingebettete Anwendung Schadsoftware war. Die Vertrauensprobleme des Busses drehen sich darum, ob das veröffentlichte Manifest das LLM des empfangenden Dokuments zu manipulieren versucht. Die Einschränkung formt das Protokoll: kleine deklarative Manifeste, festes Schema, keine Freitextfelder, die ungeprüft in Prompts fließen.

Die Persistenz endet mit der Sitzung

Ein so organisierter Bus hat kein Gedächtnis über Sitzungen hinweg. Öffnen Sie drei Dokumente, hat der Bus drei Manifeste. Schließen Sie sie, ist der Bus weg. Öffnen Sie morgen eines der Dokumente, kündigt es sich einem Bus an, auf dem an diesem Tag nur es selbst ist. Es gibt keinen dauerhaften Graphen, keinen zentralen Index, nichts, was das Schließen der Browser-Tabs überlebt.

Das ist eine bewusste Entscheidung. Das ganze Versprechen des Formats lautet, dass die Datei die Sache selbst ist. Ein dauerhafter dokumentübergreifender Speicher hieße, dass der Arbeitsbereich irgendwo lebt: in einer Datenbank, einem Dienst, einer versteckten Koordinationsdatei. Jede dieser Optionen ist ein Schritt weg von „schicken Sie das Dokument per E-Mail, und der Empfänger hat es“. Der Bus bleibt auf die Sitzung beschränkt, weil die Alternative genau das beschädigt, was das Format verteidigbar macht.

Der Preis ist real. Ein Nutzer mit hundert zusammengehörigen Dokumenten bekommt keinen Knowledge Graph. Er bekommt einen Knowledge Graph über die Dokumente, die er gerade offen hat. Für die meisten Anwendungsfälle (ich arbeite heute an den Unterlagen dieses Kunden) ist das genau der richtige Umfang. Für den Anwendungsfall zeig mir alles, was ich je über diesen Kunden geschrieben habe ist der Bus nicht die Antwort. Die Antwort ist eine Suche über Dateien, und das ist ein anderes Werkzeug.

Was das ermöglicht, was Einbettung nicht konnte

Einbettung ließ Sie ein Diagramm in ein Dokument setzen. Der Bus lässt ein Dokument wissen, dass es ein Diagramm gibt. Das klingt ähnlich, ist es aber nicht.

Ein Dokument, das seine Peers kennt, kann über das LLM auf dieses Wissen reagieren. Der Vertrag kann beantworten: passe ich zu dem Budget, das gerade offen ist. Die Besprechungsnotizen können beantworten: welche Entscheidungen dieser Besprechung betrafen offene Verträge. Das Budget kann beantworten: welche Annahmen stammen aus dem Vertrag. Keine dieser Fragen verlangt, dass die Dokumente ineinander zeichnen. Sie verlangen nur, dass die Dokumente die Manifeste der anderen hören und dass ein LLM über die Gesamtheit schlussfolgern kann.

Einbettung ließ Dokumente Pixel teilen. Der Bus lässt Dokumente Urteilsvermögen teilen. Das Diagramm im Dokument war eine visuelle Funktion. Ein Vertrag, der weiß, dass es zu ihm ein Budget gibt, ist eine analytische. Das Erste setzt Ergebnisse zusammen. Das Zweite setzt Bedeutung zusammen.

Diesen Schritt konnte die Einbettung nicht machen, weil in ihrem Bild kein LLM vorkam. OLE war ein Protokoll aus einer Welt, in der Dokumente nicht nachdachten. Ein Dokument auf dem Bus denkt über jedes andere Dokument auf dem Bus nach, in den Worten des Nutzers, in dem Moment, in dem er fragt.

Was der Bus nicht ist

Der Bus ist keine Echtzeit-Zusammenarbeit. Zwei Nutzer, die dasselbe Dokument in verschiedenen Browsern offen haben, sind nicht auf demselben Bus. Der Geltungsbereich des Null-Origins ist dieser Rechner, dieser Browser-Kontext. Nichts in diesem Protokoll überschreitet die Grenze eines Rechners. Dafür bräuchte es einen Server, und ein Server ist genau das, was das Format von seiner Struktur her zu vermeiden versucht.

Der Bus ist keine Datenbank. Manifeste sind keine Datensätze. Es gibt keine Abfragesprache, keine Schema-Durchsetzung, keine Persistenz. Die Runtime bietet dem LLM eine Liste an, das sind die Dokumente, von denen ich gehört habe, und das LLM erledigt den Rest. Wer vom Bus verlangt, sich wie eine Datenbank zu verhalten, verlangt, dass er etwas anderes ist.

Der Bus ist kein Knowledge Graph im Sinne von Notion oder Roam. Diese Werkzeuge sind von ihrer Anlage her zentralisiert: ein Arbeitsbereich, eine Quelle der Wahrheit, eine Engine, die alles indexiert. Der Bus ist das Gegenteil: kein Zentrum, keine Quelle der Wahrheit, kein Indexer. Jedes Dokument ist die Autorität für sich selbst, und den Graphen gibt es nur, solange die Dokumente gleichzeitig offen sind.

Wo das Format damit steht

Der vorherige Beitrag hat argumentiert, dass eine HTML-Datei mit eingebettetem LLM die Einheit der neuen Office-Suite ist. Der Bus ist die Antwort auf was ist der Arbeitsbereich.

Der Arbeitsbereich ist ein Ordner mit HTML-Dateien. Wenn Sie sie öffnen, hören sie einander. Wenn Sie sie schließen, verstummen sie. Der Ordner auf der Festplatte ist die dauerhafte Schicht, der Bus im Browser die aktive. Das Projekt eines Teams ist der Ordner. Die Sitzung eines Nutzers ist die Teilmenge des Ordners, die gerade offen ist.

Das ist dasselbe Modell, das Desktops seit jeher verwenden (Dateien in Ordnern, der Nutzer öffnet, was er braucht), erweitert um eine Eigenschaft, die Dateien noch nie hatten. Offene Dateien wissen jetzt von den anderen offenen Dateien. Dieses Wissen reist nicht mit dem Dokument, verschmutzt seinen Inhalt nicht und überlebt die Sitzung nicht. Es existiert, solange es nützlich ist, und hört auf zu existieren, wenn es das nicht mehr ist.

Die Office-Suite versuchte, die dokumentübergreifende Komposition über Einbettung zu lösen. Die Integration war eng und die Fehlerbilder spröde. Der Bus löst ein kleineres Problem mit einem lockereren Protokoll: Dokumente veröffentlichen, was sie sind, hören auf das, was sie interessiert, und denken über den Rest nach. Es muss keine Anwendung installiert, kein Server betrieben und kein zentraler Speicher verwaltet werden.

Die Dokumente reden miteinander. Niemand sitzt dazwischen.

Quelle und Spezifikation: github.com/ikangai/rewritable Der vorherige Beitrag: The document is the application

Aus dem Englischen übersetzt: zum Originalbeitrag