Iframes als universales Kompositions-Primitive.
Jeder Container-Service – Terminal, Display, Dateien, Code-Editor, Browser, SQLite-UI – ist eine iframe-einbettbare URL.
Eine HTML-Datei + iframes = benutzerdefinierte Infrastruktur-UI · kein SDK · kein postMessage
Kein Dashboard über deine Infra bauen. Aus deiner Infra zusammenstellen.
Herkömmliche Dashboards lesen die Datenbank, pollen APIs, rendern Zahlen und Diagramme. Ein Hoody-Dashboard bettet iframes der überwachten Services ein.
Keine Polling-Schicht
Das Dashboard pollt keinen Monitoring-Endpunkt. Es bettet die ueberwachte Sache ein.
Lesen und handeln
Metric-Spike gesehen? In das eingebettete Terminal daneben klicken und `top` tippen. Kein Kontextwechsel.
Pro-Kunde, pro-Projekt, pro-Umgebung
Dashboards aus URLs zusammenstellen — jede Kombination ist ein Dashboard.
AI-composable
Ein LLM kann HTML mit iframe-URLs ausgeben. Benutzerdefinierte Observability-UI, auf Abruf generiert.
Das iframe ist reaktiv.
HTTP POST an den Service, das iframe spiegelt den neuen Zustand. Keine postMessage-Hacks.
App bettet Service-URL ein
Elternseite setzt einen iframe ein, der auf eine Container-Service-URL zeigt.
App sendet eine HTTP-Steuerungsanfrage
POST /api/v1/files/upload (or any other API call) — authenticated against the same container.
Iframe lädt frischen Zustand
Auto-Refresh, SSE oder Benutzerinteraktion löst eine neue Anfrage aus. Die neue Datei ist im iframe sichtbar.
Kein Wrapper-Protokoll
Deine App sendet nie postMessage an den iframe. Sie aktualisiert einfach den Container; der iframe sieht die Änderung bei seiner naechsten Anfrage.
Iframes rendern auf jedem Browser. Jeder Browser ist auf jedem Gerät.
Ein eingebettetes Hoody-Dashboard funktioniert auf einem Telefon. Auf einem Tablet. Auf einem TV-Browser. Auf einer Smartwatch. Auf dem Browser eines VR-Headsets.
Das Kompositions-Primitiv ist iframe + HTTPS. Beide sind universell. Das ist der einzige Grund, warum Geräte-Paritaet automatisch ist.
Ein LLM kann ein Dashboard aus Container-URLs zusammenstellen.
Einen Agent fragen: 'Bau mir ein Health-Check-Dashboard für diese drei Container.' Er gibt HTML mit iframe-Tags aus.
Agent empfaengt die Spezifikation
'Ich muss drei Container überwachen: Frontend, Backend, DB. Das Terminal-Log jedes einzelnen anzeigen.'
Agent gibt HTML aus
Template mit drei iframe-Tags, die auf die richtigen terminal-1-URLs für jeden Container zeigen.
Von überall bereitstellen
In eine statische Datei, eine Notion-Seite mit iframe-Einbettung oder einen dedizierten Hoody-Container einfuegen, der http-3000 betreibt.
Die URL öffnen
Live-Dashboard. Aus der Infrastruktur zusammengestellt, nicht aus einem Dashboard-Produkt.
Wo Einbettbarkeit an die Grenzen des Browsers stoesst.
Iframes sind ein Browser-Primitiv. Der Browser setzt Regeln durch, was eingebettet werden kann. Das sind universelle Einschränkungen.
X-Frame-Options / CSP
Externe URLs, die X-Frame-Options: DENY oder frame-ancestors 'none' setzen, können nicht eingebettet werden. Hoody's eigene Services setzen das nicht.
Mixed Content
Eine HTTP-URL in einer HTTPS-Seite einzubetten, wird blockiert. Hoody-URLs sind immer HTTPS — funktioniert überall.
Third-Party-Cookies
Browser blockieren zunehmend Third-Party-Cookies. Auth in eingebetteten iframes benötigt möglicherweise Per-Request-Tokens statt Session-Cookies.
Third-Party-Storage
localStorage innerhalb eines iframe ist auf die Origin des iframe beschränkt. Cross-iframe-Status muss aus der Container-API kommen.
Dein erster Embed ist eine Zeile HTML.
Eine iframe-Tag in deine Seite einfügen, src auf eine Service-URL zeigen. Das ist es.
Siehe auch — /platform/os für Komposition innerhalb von Hoody, /kit/workspaces für die Workspace-Laufzeit, /methods/multiplayer für Multiplayer.