iris/iris-plugins
1
0
Fork 0
Code Issues 17 Pull requests Projects Releases Packages Wiki Activity Actions

Gateway für den Web-Client: Vertrag + Plugin iris-web-linux + Installer-Dienste (Voraussetzung für iris/iris-web#1 Schritt 3+4) #346

New issue
Open
opened 2026-11-05 10:45:25 +00:00 by alf · 3 comments
alf commented 2026-11-05 10:45:25 +00:00
Owner
Copy link

Worum es hier geht

Der Browser-Zweig von iris/iris-web#1 (Schritte 3 und 4 im Plan) hat seit Ende Oktober kein
offenes Issue mehr, obwohl die Arbeit nicht existiert. Die beiden Voraussetzungen sind
kommentarlos geschlossen:

  • iris/iris-linux-server#74 — „Plugin-Installer: Dienste (Sidecar-Container) unterstützen",
    geschlossen 2026-10-27, kein Kommentar.
  • iris/iris-plugins#166 — „Plugin iris-web-linux: Gateway für den Web-Client +
    Gateway-Vertrag", geschlossen 2026-10-22, kein Kommentar.

Beide trugen typ/idea. Was davon noch gilt, steht in frontend/iris-web/CLAUDE.md und in
frontend/iris-web/obsidian-docs/plans/ENTSCHEIDUNGEN.md (Entscheidung 3: Installer lernt
Dienste; 4: Passwort-Login; 5: Master-Token; 8: Python/FastAPI).

Gemessen am 2026-11-05, nichts davon ist gebaut

  • linux-server/iris-server/app/plugin_installer.py schreibt in seinem eigenen Docstring
    weiterhin „Keine pre_install/post_install-Hook-Ausführung … Bewusst nicht
    unterstützt statt blind auszuführen". sidecar hat im ganzen Server-Repo keinen Treffer,
    kein plugin.json im plugins/-Repo hat ein Dienste-Feld.
  • In Entwicklerdokumentation/ liegt kein Gateway-Vertrag — die Projekt-CLAUDE.md
    verweist auf einen, es gibt ihn nicht.
  • Kein Plugin-Ordner plugins/iris-web-linux; die Registry (plugin-registry, nach Pull)
    führt ihn nicht.

Was zu tun ist, wenn der Browser-Zweig kommen soll

  1. Gateway-Vertrag als Dokument in Entwicklerdokumentation/: Login, Session, Logout,
    Weiterleitung der Wire-Protokoll-Aufrufe und SSE-Streams. Beide Gateways (Linux, später
    Mac) müssen ihn identisch bedienen.
  2. Installer lernt Dienste (iris/iris-linux-server): Manifest-Feld, Secrets,
    Lebenszyklus bei Install/Deinstall/Neustart, Backup, erlaubte Compose-Optionen.
  3. Plugin iris-web-linux (Python/FastAPI im Container) mit pytest-Vertragstests.
  4. Danach iris/iris-web#1 Schritt 4: WASM-Bundle ins Plugin, Verteilung, Updater.

Punkt 2 ist die Voraussetzung für 3 und der einzige, der den Server-Kern anfasst.

Grenzen

Ob die beiden alten Issues bewusst geschlossen wurden (andere Absicht, ersetzt durch etwas
anderes) oder versehentlich, ist aus dem Verlauf nicht zu entnehmen — keiner hat einen
Kommentar hinterlassen. Dieses Issue beschreibt nur, was nicht existiert; es entscheidet
nicht, ob der Browser-Zweig gebaut wird. Der Desktop-Client funktioniert ohne das Gateway
(iris/iris-web#1).

## Worum es hier geht Der Browser-Zweig von `iris/iris-web#1` (Schritte 3 und 4 im Plan) hat seit Ende Oktober **kein offenes Issue mehr**, obwohl die Arbeit nicht existiert. Die beiden Voraussetzungen sind kommentarlos geschlossen: - `iris/iris-linux-server#74` — „Plugin-Installer: Dienste (Sidecar-Container) unterstützen", geschlossen 2026-10-27, **kein Kommentar**. - `iris/iris-plugins#166` — „Plugin iris-web-linux: Gateway für den Web-Client + Gateway-Vertrag", geschlossen 2026-10-22, **kein Kommentar**. Beide trugen `typ/idea`. Was davon noch gilt, steht in `frontend/iris-web/CLAUDE.md` und in `frontend/iris-web/obsidian-docs/plans/ENTSCHEIDUNGEN.md` (Entscheidung 3: Installer lernt Dienste; 4: Passwort-Login; 5: Master-Token; 8: Python/FastAPI). ## Gemessen am 2026-11-05, nichts davon ist gebaut - `linux-server/iris-server/app/plugin_installer.py` schreibt in seinem eigenen Docstring weiterhin „**Keine `pre_install`/`post_install`-Hook-Ausführung** … Bewusst nicht unterstützt statt blind auszuführen". `sidecar` hat im ganzen Server-Repo keinen Treffer, kein `plugin.json` im `plugins/`-Repo hat ein Dienste-Feld. - In `Entwicklerdokumentation/` liegt **kein** Gateway-Vertrag — die Projekt-`CLAUDE.md` verweist auf einen, es gibt ihn nicht. - Kein Plugin-Ordner `plugins/iris-web-linux`; die Registry (`plugin-registry`, nach Pull) führt ihn nicht. ## Was zu tun ist, wenn der Browser-Zweig kommen soll 1. **Gateway-Vertrag als Dokument** in `Entwicklerdokumentation/`: Login, Session, Logout, Weiterleitung der Wire-Protokoll-Aufrufe und SSE-Streams. Beide Gateways (Linux, später Mac) müssen ihn identisch bedienen. 2. **Installer lernt Dienste** (`iris/iris-linux-server`): Manifest-Feld, Secrets, Lebenszyklus bei Install/Deinstall/Neustart, Backup, erlaubte Compose-Optionen. 3. **Plugin `iris-web-linux`** (Python/FastAPI im Container) mit pytest-Vertragstests. 4. Danach `iris/iris-web#1` Schritt 4: WASM-Bundle ins Plugin, Verteilung, Updater. Punkt 2 ist die Voraussetzung für 3 und der einzige, der den Server-Kern anfasst. ## Grenzen Ob die beiden alten Issues bewusst geschlossen wurden (andere Absicht, ersetzt durch etwas anderes) oder versehentlich, ist aus dem Verlauf nicht zu entnehmen — keiner hat einen Kommentar hinterlassen. Dieses Issue beschreibt nur, was **nicht** existiert; es entscheidet nicht, ob der Browser-Zweig gebaut wird. Der Desktop-Client funktioniert ohne das Gateway (`iris/iris-web#1`).
alf commented 2026-11-05 10:51:34 +00:00
Author
Owner
Copy link

Kurze Klarstellung: dieses Issue war kurz geschlossen, weil ein Docs-Commit (iris/iris-web PR #12) ohne -r eingereicht wurde und es deshalb automatisch geschlossen hat. Wieder geöffnet — die Arbeit ist nicht getan, es existiert nichts davon. PR #12 ändert nur die Verweise in session-kontext.md (und in PLAN.md, die im Vault liegt).

Kurze Klarstellung: dieses Issue war kurz geschlossen, weil ein Docs-Commit (`iris/iris-web` PR #12) ohne `-r` eingereicht wurde und es deshalb automatisch geschlossen hat. Wieder geöffnet — die Arbeit ist **nicht** getan, es existiert nichts davon. PR #12 ändert nur die Verweise in `session-kontext.md` (und in `PLAN.md`, die im Vault liegt).
alf commented 2026-11-08 22:10:19 +00:00
Author
Owner
Copy link

PR #166 gemergt: docs(entwicklerdoku): Entwurf Gateway-Vertrag (iris/iris-plugins#346)
http://docker:3000/alf/2ndbrain/pulls/166

Commits:

Entwurf des Gateway-Vertrags: Entwicklerdokumentation/19-Gateway-Vertrag.md. Das ist ein Vorschlag, nichts davon ist entschieden.

Was drin steht: Zwei Namensräume (/gw/… für das Gateway, /api/… als durchgereichtes Wire-Protokoll, Bundle auf /), Login/Sitzung/Logout/Health mit Cookie-Attributen und Rate-Limit, CSRF-Schutz, Weiterleitung per Allowlist (mit Begründung), Header-Regeln und Gateway als Gerät (X-Device-ID, Token-Rotation), Streams (SSE ohne Pufferung), Downloads, Uploads, Zeitlimits, HTML-Server, was es im Browser zunächst nicht gibt (Terminal, Remote Desktop, Geräteverwaltung), Versionierung (contract: 1) und die pytest-Vertragstests. Fest (aus den Entscheidungen 3–6 und 8) und Vorschlag sind getrennt; am Ende steht eine Tabelle mit 10 offenen Entscheidungen, je mit Vorschlag und Alternative.

Ein Punkt, der die Richtung bestimmt: Der Mac-Server hat Routen ohne Anmeldung nur für Loopback (/notify, /job-watch/start, /job-callback/register, POST /vault/translate, POST /claude-code/terminal) und verlangt für Terminal und Remote Desktop keine Geräte-Freigabe bei Loopback-Verbindungen. iris-web-mac liefe auf demselben Rechner, das Gateway wäre für den Server also Loopback; ein Gateway, das alles durchreicht, öffnete diese Routen jedem angemeldeten Browser. Deshalb schlägt der Entwurf eine Allowlist vor (mit einem Test, der prüft, dass jede Route des Wire-Protokolls in genau einer Gruppe steht). Der Linux-Server hat diese Ausnahmen nicht; die Allowlist gilt trotzdem für beide, weil der Vertrag identisch sein soll.

Geprüft: Das Mermaid-Diagramm (gültig); Aussagen zum Server gegen 02-Wire-Protokoll.md und den Code des Linux-Servers abgeglichen (dabei eine Falschaussage im ersten Entwurf gefunden und korrigiert: die Loopback-Ausnahme gibt es nur auf dem Mac).

Nicht geprüft: Kein Gateway gebaut und nichts gegen einen echten Server ausprobiert. Die Zahlen (Sitzungsdauer, Rate-Limit, Upload-Grenze) sind Vorschläge ohne Messung. Die Allowlist steht nur als Familien, nicht Route für Route; Grundlage wäre linux-server/ROUTES.md, nicht gegen den Stand der Routen abgeglichen.

PR #166 gemergt: docs(entwicklerdoku): Entwurf Gateway-Vertrag (iris/iris-plugins#346) http://docker:3000/alf/2ndbrain/pulls/166 Commits: - docs(entwicklerdoku): Entwurf Gateway-Vertrag (iris/iris-plugins#346) --- **Entwurf des Gateway-Vertrags:** `Entwicklerdokumentation/19-Gateway-Vertrag.md`. Das ist ein **Vorschlag, nichts davon ist entschieden.** **Was drin steht:** Zwei Namensräume (`/gw/…` für das Gateway, `/api/…` als durchgereichtes Wire-Protokoll, Bundle auf `/`), Login/Sitzung/Logout/Health mit Cookie-Attributen und Rate-Limit, CSRF-Schutz, Weiterleitung per **Allowlist** (mit Begründung), Header-Regeln und Gateway als Gerät (`X-Device-ID`, Token-Rotation), Streams (SSE ohne Pufferung), Downloads, Uploads, Zeitlimits, HTML-Server, was es im Browser zunächst nicht gibt (Terminal, Remote Desktop, Geräteverwaltung), Versionierung (`contract: 1`) und die pytest-Vertragstests. **Fest** (aus den Entscheidungen 3–6 und 8) und **Vorschlag** sind getrennt; am Ende steht eine Tabelle mit **10 offenen Entscheidungen**, je mit Vorschlag und Alternative. **Ein Punkt, der die Richtung bestimmt:** Der Mac-Server hat Routen ohne Anmeldung nur für Loopback (`/notify`, `/job-watch/start`, `/job-callback/register`, `POST /vault/translate`, `POST /claude-code/terminal`) und verlangt für Terminal und Remote Desktop keine Geräte-Freigabe bei Loopback-Verbindungen. `iris-web-mac` liefe auf demselben Rechner, das Gateway wäre für den Server also Loopback; ein Gateway, das alles durchreicht, öffnete diese Routen jedem angemeldeten Browser. Deshalb schlägt der Entwurf eine Allowlist vor (mit einem Test, der prüft, dass jede Route des Wire-Protokolls in genau einer Gruppe steht). Der Linux-Server hat diese Ausnahmen nicht; die Allowlist gilt trotzdem für beide, weil der Vertrag identisch sein soll. **Geprüft:** Das Mermaid-Diagramm (gültig); Aussagen zum Server gegen `02-Wire-Protokoll.md` und den Code des Linux-Servers abgeglichen (dabei eine Falschaussage im ersten Entwurf gefunden und korrigiert: die Loopback-Ausnahme gibt es nur auf dem Mac). **Nicht geprüft:** Kein Gateway gebaut und nichts gegen einen echten Server ausprobiert. Die Zahlen (Sitzungsdauer, Rate-Limit, Upload-Grenze) sind Vorschläge ohne Messung. Die Allowlist steht nur als Familien, nicht Route für Route; Grundlage wäre `linux-server/ROUTES.md`, nicht gegen den Stand der Routen abgeglichen.
alf commented 2026-11-11 13:39:24 +00:00
Author
Owner
Copy link

Hinweis aus iris/rust-iris-nx#1 (2026-11-11): Sobald der Linux-Server Sessions kennt (iris/iris-linux-server#151, Entwurf Entwicklerdokumentation/20-Sessions-Entwurf.md), braucht die Allowlist des Gateways die neuen Routen (/sessions…, dazu das Feld session_id in POST /agent und den neuen Fehler 409 session_busy). Der Vertragstest (jede Route des Wire-Protokolls in genau einer Gruppe) schlägt sonst fehl. Für den Mac-Gateway stehen sie unter „nicht vorhanden“, weil der Mac-Server die Fähigkeit nicht hat. Bis das Gateway existiert, nutzt rust-iris-nx einen Entwicklungs-Transport und ist davon nicht blockiert.

**Hinweis aus `iris/rust-iris-nx#1` (2026-11-11):** Sobald der Linux-Server Sessions kennt (`iris/iris-linux-server#151`, Entwurf `Entwicklerdokumentation/20-Sessions-Entwurf.md`), braucht die **Allowlist** des Gateways die neuen Routen (`/sessions…`, dazu das Feld `session_id` in `POST /agent` und den neuen Fehler `409 session_busy`). Der Vertragstest (jede Route des Wire-Protokolls in genau einer Gruppe) schlägt sonst fehl. Für den Mac-Gateway stehen sie unter „nicht vorhanden“, weil der Mac-Server die Fähigkeit nicht hat. Bis das Gateway existiert, nutzt `rust-iris-nx` einen Entwicklungs-Transport und ist davon nicht blockiert.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
  
herkunft/alpha-feedback
Aus Rückmeldungen der Alpha-Tester

  
status
blockiert
 Wartet auf etwas anderes

  
status
zu-testen
 Gebaut, aber noch nicht im echten Einsatz geprüft

  
typ
bug
 Fehler

  
typ
docs
 Dokumentation

  
typ
enhancement
 Verbesserung einer vorhandenen Funktion

  
typ
feature
 Neue Funktion

  
typ
idea
 Idee, noch nicht entschieden

No labels
herkunft/alpha-feedback
status
blockiert
status
zu-testen
typ
bug
typ
docs
typ
enhancement
typ
feature
typ
idea
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
iris/iris-plugins#346
No description provided.