BrĂŒcke RZ ⟷ Crumbforest: zwei Schreiber, viele Leser

Status: PROPOSAL / PRE-CODE. Nichts davon ist gebaut, nichts ist im RZ geprĂŒft.
Stand: 2026-10-02
Von: Branko, mit der Ansiblekatze (Mac-Steuerknoten)
An: OZMAI / Alex. Zum Lesen, wenn es in die Arbeit passt. Keine Antwort nötig.
Ablage: Inbox. Keine AutoritÀt, kein Brain-Status (siehe 00_README_AND_RULES.md).

Keine Zugangsdaten, SchlĂŒssel oder Adressen in diesem Dokument.

0. Warum dieses Handout

OZMAI hat den Kontext zu diesem Gedanken noch nicht. Er entstand heute Abend aus einer Nebenfrage und wird hier in einem StĂŒck abgelegt, damit er nicht verloren geht und nicht in Teilen ankommt.

Der Gedanke in einem Satz:

Die BrĂŒcke entsteht dort, wo mehrere Nutzer per SSH im RZ lesen. Geschrieben wird nur von zwei Seiten, OZM und Crumbforest, jede in ihre eigene Quelle.

1. Kontext in wenigen Zeilen

  • Heute gefunden: das Open-Source-Projekt omnyssh (Rust, Apache-2.0, ratatui/Tauri). Wir ĂŒbernehmen keinen Code, nur Ideen. Herkunft wird im Crate genannt.
  • Daraus entstand eine Architektur-Skizze fĂŒr einen headless Core: der Server liefert nur Daten, die Clients tragen den Core (Sessions, Metrics, SFTP, Snippets).
    Ablage in unserem Repo: docs/questions-core_SKIZZE_client-core_ssh.md.
  • Die Skizze beantwortet noch nicht, wer im RZ was schreiben darf. Das ist der Teil dieses Handouts.

2. Der Vorschlag

 OZM-DomÀne (RZ)               Crumbforest-DomÀne (Wald)
 Schreiber: ozm                Schreiber: crumbforest
 eigene Quelle                 eigene Quelle
      │ nur anhĂ€ngen                 │ nur anhĂ€ngen
      ▌                              ▌
 LeseflÀche OZM (ro)           LeseflÀche Crumbforest (ro)
      └───────────────┬──────────────┘
                      │ SSH, nur lesen
           ┌──────────▌───────────┐
           │ viele Leser          │  eine Sicht wird erst beim Lesen
           │ (ein Key je Handle)  │  zusammengelegt, nie gespeichert
           └──────────────────────┘

Leitsatz: zwei Schreiber, viele Leser, kein dritter Schreiber.

3. Regeln (alle PROPOSAL)

  1. Kein Fakt hat zwei EigentĂŒmer. Jeder Fakt gehört genau einer DomĂ€ne. Die andere Seite verweist per ID oder Hash darauf, sie kopiert ihn nicht.
  2. Schreiben kreuzt die Grenze nie, nur Lesen. Der Austausch lÀuft nach eurem Inbox-Transportkanon: read-only Pull, at-least-once, Dedup, ACK höchstens bis STORED_BY_RELAY. Mechanik geteilt, Bedeutung getrennt.
  3. ZusammenfĂŒhrung ist Ableitung. Eine kombinierte Sicht entsteht beim Lesen im Client oder als wegwerfbare Ableitung. Die Quelle bleibt heilig.
  4. Erzwungen durch das System, nicht durch Absprache. Zwei Schreiber-Konten, jedes schreibt nur in sein Verzeichnis. Leser sind in einer Lesegruppe, mit SFTP nur lesend (internal-sftp -R) oder einer festen Lese-Befehlsliste (ForceCommand).
  5. Berechtigung ist ein Vertrag, kein GerĂ€tefeld. Welcher Leser welche DomĂ€ne lesen darf, steht als Bindung im questions-core-Vertrag, nicht in NetBox (Berechtigung ≠ Ding).
  6. Lesen erzeugt Evidenz, keine Überwachung. Ein Lesebeleg trĂ€gt Key-Handle, Zeit und Datei-Revision, keinen Inhalt. Ob das RZ solche Belege will, entscheidet OZM.

Dazu aus der Skizze: Leser fĂŒhren im Core nur Snippets mit effect = Read aus. Schreibende Snippets gibt es nur fĂŒr die zwei Schreiber-IdentitĂ€ten. Wirkung hĂ€ngt am Gate, und Refusals fĂŒhren nie aus.

4. Bezug zu dem, was ihr schon habt

Bezug Wie wir es lesen Status
OZM-Inbox-Transportkanon trÀgt die Mechanik von Regel 2 unsere Lesart, bitte gegenlesen
Eine SerialisierungsautoritÀt je DomÀne (Tokio-Serialization-Canon) zwei DomÀnen = zwei AutoritÀten, keine gemeinsame OPEN: ist ozm eine AutoritÀt?
FĂŒnf Achsen (Bedeutung, Berechtigung, Wirkung, Evidenz, Verwahrung) Regel 5 = Berechtigung, Regel 6 = Evidenz, LeseflĂ€che = Verwahrung unsere Lesart
Safety-Grenze des Waldes BrĂŒcke trĂ€gt nur Lesen/Rendern, aktuiert nichts aus unserer Notiz vom 10.09., nicht neu geprĂŒft
Keine externe KI im RZ der Core ruft im RZ nichts nach außen aus derselben Notiz, nicht neu geprĂŒft
Kinder-Daten ĂŒber die BrĂŒcke nur Gehashtes oder GezĂ€hltes, nie Klartext Haltung der Crumbforest-Seite

5. Klassifikation

  • EXISTING_FACT (aus unserer Notiz, nicht heute geprĂŒft): RZ auf Proxmox/OPNsense, unabhĂ€ngig von Strato. Auf dem Tesla-Host sind wir nicht root und es ist noch kein SSH-Key hinterlegt. Zeitpunkt der Notiz: 2026-09-10.
  • DESIGN_INTENT: Core/Server-Trennung aus der Skizze.
  • PROPOSAL: alles in Abschnitt 2 und 3.
  • UNKNOWN: siehe Abschnitt 6. Nichts davon wird hier geraten.

6. Offen, an OZMAI und Alex

  1. Wer sind ozm und crumbforest als Schreiber technisch: zwei Unix-Konten, zwei Dienste, zwei Keys? Und ist ozm eine Schreib-AutoritÀt oder mehrere?
  2. Wo trifft sich ein Fakt, den beide Seiten brauchen, ohne zwei EigentĂŒmer zu haben? Unser Vorschlag ist ein ID-Verweis. Das sollte an zwei oder drei echten Beispielen geprĂŒft werden, bevor es Regel wird.
  3. Wer legt im RZ die zwei Schreiber-Konten und die Lesegruppe an? Wir können es vorschlagen, aber nicht tun.
  4. Will das RZ Lesebelege (Regel 6), und wo werden sie verwahrt?
  5. Welche RZ-Hosts wĂ€ren ĂŒberhaupt LeseflĂ€che? Der NetBox-Stand im RZ war am 10.09. „wird hochgefahren"; wir haben ihn nicht neu geprĂŒft.
  6. Passt die Trennung der Berechtigung (Vertrag) von den Dingen (NetBox) auch auf eurer Seite, oder habt ihr dafĂŒr schon einen anderen Ort?

7. Was wir ausdrĂŒcklich nicht vorschlagen

  • Keinen gemeinsamen beschreibbaren Ort fĂŒr beide Seiten.
  • Keinen automatischen Abgleich, der Fakten vereinheitlicht.
  • Keinen Schreibzugriff fĂŒr Leser, auch nicht zeitweise.
  • Keinen Eingriff in Safety oder Aktuatorik ĂŒber diese BrĂŒcke.
  • Keine Übernahme von omnyssh-Code. Dessen One-Click-Key-Setup (schreibt auf Remote-Hosts) passt nicht zu diesem Vorschlag.

8. Unsicherheit

Die Skizze und dieses Handout wurden heute Abend in einem GesprĂ€ch erarbeitet. Von omnyssh habe ich nur README, Cargo-Datei und Signaturen gelesen, nicht den vollen Code. Über das RZ weiß diese Seite nur das, was in den Notizen steht. Wenn etwas hier eurem Bild widerspricht, gilt euer Bild.