Ich wurde gefeuert. Das hier hab ich stattdessen gebaut.

Die Entstehungsgeschichte

Mein Tagesjob hatte ein Widget-Problem. Andere Websites haben unser JavaScript eingebunden, um ein Widget anzuzeigen - ein Formular, eine Chat-Blase, ein Dashboard-Panel. Das Script war langsam, aufgebläht, lahm beim Laden. Drittanbieter-Seiten, die es eingebunden haben, haben das deutlich gespürt. In meiner Freizeit hab ich angefangen, einen Ersatz zu bauen.

Der Prototyp wurde besser als erwartet. SSR- und CSR-Support - SSR für Geschwindigkeit, CSR für Interaktivität. Unter 15 KB gesamt. Schneller als die Tagesjob-Version. Mehr Features. Komplett reaktiv, komplett typsicher. Ein sauberes postMessage-Protokoll zwischen iframe und Hostseite. Kein geteilter State. Trigger-System, Anzeigemodi, Frequenzsteuerung. Ich wollte es meinem Team zeigen. Dann wurde ich gefeuert.

Die Codebase lag dann etwa sechs Monate auf meiner Festplatte. Dann wurde mir klar, wofür next-vibe sie wirklich brauchte: nicht nur Formulare - sondern die vollständige interaktive UI eines Tools, das auf einem Remote-Server läuft, in einer Sandbox, auf jeder Seite. Das ist Remote-Tool-Ausführung mit Live-UI.

Das Problem mit Script-Tags

Wenn du Drittanbieter-Inhalte mit einem nackten Script-Tag einbindest, zahlst du doppelt. Performance: Das Script muss laden, parsen und ausführen, bevor irgendetwas gerendert wird. Wenn der Drittanbieter-Server langsam ist, wartet deine Seite. Und Sicherheit: Das Script hat vollen Zugriff auf die Seite - DOM, Cookies, localStorage, Event-Listener. Wenn es fehlerhaft ist, geht deine Seite kaputt. Wenn es bösartig ist, sind deine Nutzer gefährdet.

Die sichere Alternative ist ein iframe. Aber iframes kommunizieren standardmäßig nicht mit der Elternseite. Resize-Events bubblen nicht hoch. Formular-Submits propagieren nicht. Am Ende hast du eine isolierte Box, die ihrem Parent nichts mitteilen kann.

Die postMessage-Brücke

Jede Nachricht hat das Präfix vf:. Die Elternbrücke validiert den Origin, bevor sie irgendetwas verarbeitet. Der iframe wird nie im Kontext der Hostseite ausgeführt.

Anzeigemodi und Auslöser

Vier Anzeigemodi

Sieben Auslöser-Typen

Zwei Script-Tags. Fertig.

Jeder Endpoint wird einbettbar. Das Tool läuft auf seinem eigenen Server. Das Widget rendert in einer Sandbox auf deiner Seite. Volle Funktionalität, kein geteilter State.

Der vollständige Einbettungscode für ein Kontaktformular von unbottled.ai

1import { VibeFrame } from "next-vibe/vibe-frame";
2
3VibeFrame.mount({
4  serverUrl: "https://unbottled.ai",
5  endpoint: "contact_POST",
6  target: "#contact-form",
7  trigger: { type: "immediate", display: "inline" },
8});

Oder als einfacher Script-Tag für jede beliebige Website:

1<script>
2  window.vibeFrameConfig = {
3    serverUrl: "https://unbottled.ai",
4    integrations: [{
5      endpoint: "contact_POST",
6      target: "#contact-form",
7      trigger: { type: "immediate", display: "inline" },
8    }],
9  };
10</script>
11<script src="https://unbottled.ai/vibe-frame/vibe-frame.js"></script>

Kein Nebeneffekt. Der eigentliche Punkt.

Als ich VibeFrame in next-vibe portiert hab, war der erste echte Einsatz nicht, ein Kontaktformular auf irgendeiner externen Seite einzubetten. Es war Remote-Tool-Ausführung innerhalb der Plattform selbst - die vollständige interaktive Widget-UI eines beliebigen Endpoints in einer Sandbox rendern, damit sich verteilte Tools wie ein System anfühlen.

Echte Daten. Live-Indikatoren. Ein Vibe Sense Graph reagiert auf das, was auf dem Server passiert. Das ist kein Screenshot und kein statischer Export. Das Tool läuft. VibeFrame rendert seine Widget-UI in einer Sandbox, wo immer du sie brauchst - innerhalb der Plattform, auf einem Dashboard oder auf jeder anderen Seite.

Föderiertes Einbetten

Jede VibeFrame-Integration kann auf eine andere serverUrl zeigen. Das heißt: Du kannst Widgets von mehreren next-vibe-Instanzen auf derselben Seite einbetten. Kein gemeinsames Backend. Keine gemeinsame Datenbank.

Mehrere Instanzen, eine Hostseite, null geteilte Infrastruktur

1import { VibeFrame } from "next-vibe/vibe-frame";
2
3// Chat widget from unbottled.ai
4VibeFrame.mount({
5  serverUrl: "https://unbottled.ai",
6  endpoint: "agent_chat_threads_GET",
7  target: "#chat",
8});
9
10// Product catalog from a shop instance
11VibeFrame.mount({
12  serverUrl: "https://shop.example.com",
13  endpoint: "products_GET",
14  target: "#products",
15  trigger: { type: "scroll", scrollPercent: 30, display: "modal" },
16});
17
18// Analytics dashboard from yet another instance
19VibeFrame.mount({
20  serverUrl: "https://analytics.example.com",
21  endpoint: "vibe_sense_dashboard_GET",
22  target: "#dashboard",
23  trigger: { type: "click", clickSelector: "#show-stats", display: "slideIn" },
24});

Die Aufruf-Hälfte

VibeFrame übernimmt das Rendering. Die Tool-Registry übernimmt den Aufruf. Du verbindest Remote-Instanzen von next-vibe – jede mit einem Namen wie hermes, thea oder einem eigenen Alias. Deren Endpoints werden neben deinen lokalen Tools verfügbar. Ein einheitliches Tool-Set.

Die KI nutzt tool-help, um jeden verfügbaren Endpoint zu entdecken – lokal und remote. Sie sieht die komplette Registry: Namen, Beschreibungen, typisierte Ein- und Ausgaben. Beim Aufruf von execute-tool leitet die Plattform an die richtige Instanz weiter. Der KI ist egal, wo ein Tool lebt.

Du behältst die Kontrolle. Pinne die Tools an, die du sehen willst, deaktiviere die, die du nicht brauchst. Gleiche Verwaltung für lokale und Remote-Endpoints – kein Unterschied in der Konfiguration.

Skills: eine Persona-Ebene

Darüber legen Skills eine Persona. Ein Skill ist ein Preset – ein Name, ein System-Prompt, eine Stimme, eine Persönlichkeit, und optional ein eingeschränktes Tool-Set. Der Nutzer wählt einen Tutor, einen Programmierer, einen Geschichtenerzähler. Unter der Haube ist es dieselbe Registry, dieselben Endpoints, dieselben execute-tool-Aufrufe.

Remote-Tool-Ausführung

Hier treffen VibeFrame und die Tool-Registry aufeinander. Wenn eine KI execute-tool mit einem Remote-Endpoint aufruft, leitet next-vibe den Aufruf an die Zielinstanz weiter. Die Instanz führt das Tool aus und gibt das Ergebnis zurück. Soweit Standard.

Aber jeder Endpoint in next-vibe hat auch ein Widget – eine typisierte, voll ausgestattete UI-Komponente, die weiß, wie sie die Ein- und Ausgaben des Tools rendert. Wenn die Remote-Instanz öffentlich erreichbar ist, rendert VibeFrame das echte Widget in einem Sandbox-iframe, mit Kommunikation zum Server des Tools über postMessage. Volle Interaktivität, Live-Daten, echte UI.

Wenn die Instanz nicht öffentlich ist – hinter einer Firewall, in einem privaten Netzwerk – fällt die Plattform auf Definition-getriebene UI zurück. Die Endpoint-Definition enthält genug Metadaten (Feldtypen, Labels, Validierungsregeln), um lokal eine funktionale Oberfläche zu rendern, ohne jemals das Frontend des Remote-Servers zu erreichen. So oder so funktioniert das Tool. Die UI passt sich an.

Was sie gemeinsam haben

VibeFrame und die Tool-Registry lösen dasselbe Problem von entgegengesetzten Seiten. Die Tool-Registry übernimmt den Aufruf - jeder Endpoint auf jeder Instanz, aufrufbar von jeder KI. VibeFrame übernimmt das Rendering - jedes Widget von jeder Instanz, einbettbar auf jeder Seite. Remote-Tool-Ausführung ist die Brücke: das Tool aufrufen, seine UI rendern.

Auf GitHub ansehen

1git clone https://github.com/techfreaque/next-vibe
2cd next-vibe
3cp .env.example .env
4bun install
5vibe dev