Architektur und Ablauf

Die Teile

Im Browser deiner Besucher:

• loader.js – ein kleiner Ladeteil von wenigen Kilobyte. Er liest die Konfiguration, prüft die Einwilligung, zeichnet einen Platzhalter-Launcher an seiner endgültigen Stelle (keine Layoutverschiebung) und legt window.ReactiveChat mit einer Befehlswarteschlange an. Sonst tut er nichts.
• Der Kern (core.<hash>.js) – Chatfenster, Verbindung, Maskierung persönlicher Daten, Regeln. Er wird erst nachgeladen, wenn ein Auslöser greift: Browser hat Zeit, Maus oder Finger auf dem Launcher, ein API-Befehl, ein Frustrationssignal aus MousePlayer. Die meisten Besucher öffnen den Chat nie und laden ihn deshalb auch nicht sofort.
• Module bei Bedarf – Produkt-Touren, Datenschutztext, Shop-Funktionen; jeweils erst, wenn sie gebraucht werden.
• Isolation – alles lebt in einem geschlossenen Shadow DOM; Stile über konstruierbare Stylesheets, keine Inline-Skripte, kein eval, keine Cookies.

Bei reactive.chat:

• Auslieferung unter https://cdn.reactive.chat/ – Loader, Kern, Module.
• Chat-Server unter wss://ws.reactive.chat/rc_wss/ – WebSocket mit Protokoll rc.v1; dieselbe Adresse mit https:// für HTTP-Rückfall, Offline-Formular, Uploads, Datenschutztext und Smart Answer.
• Konto unter https://reactive.chat/app – Projekteinstellungen, Gestaltung, Wissensdatenbank, Pult deines Teams.
• Server-API unter https://reactive.chat/v1/ – REST und MCP für dein Backend.

Bei dir (optional):

• Dein Backend signiert die Identität angemeldeter Nutzer, beantwortet den Kundendaten-Abruf, empfängt Webhooks und ruft die Server-API.
• Dein Proxy liefert alles über eine eigene Subdomain aus (Eigene Domain).

Ablauf eines Seitenaufrufs

1. Der Browser lädt loader.js (asynchron, blockiert nichts).
2. Der Loader liest data-rc-*, ReactiveChatSettings und vorgemerkte boot-Aufrufe, prüft den Site-Key und die Einwilligung und zeichnet den Platzhalter.
3. Ein Auslöser greift; der Loader lädt den Kern aus demselben Verzeichnis.
4. Der Kern übernimmt Platzhalter und Warteschlange und arbeitet vorgemerkte Befehle in Reihenfolge ab.
5. Er öffnet die Verbindung und schickt init mit Site-Key, Kennungen, Sprache, Einwilligung, ggf. signierter Identität und Seitenkontext.
6. Der Server prüft Herkunft, Projekt und Identität und antwortet mit init_ok: Gestaltung und Texte aus dem Konto, Regeln, Funktionen, Grenzen, bisheriger Verlauf.
7. Das Widget ist bereit (Ereignis ready). Seitenwechsel in Single-Page-Apps meldet es selbst.

Ablauf einer Frage

1. Der Besucher schreibt; persönliche Daten werden im Browser maskiert, die Nachricht trägt eine eindeutige Kennung.
2. Der Server legt sie ab (Wiederholungen erkennt er an der Kennung), maskiert erneut und bestätigt mit einem Echo.
3. Der KI-Assistent sucht in deiner Wissensdatenbank – bei Bestellfragen eines bestätigten Nutzers zusätzlich über den Kundendaten-Endpunkt – und streamt die Antwort. Wann er an dein Team übergibt, legst du im Konto fest (Handbuch).
4. Parallel gehen Ereignisse über eine Warteschlange an Webhooks und Integrationen. Ein Chat wartet nie auf sie.

Versionen und Auslieferung

• loader.js hat keine Versionsnummer im Namen und wird bei Updates ersetzt. Binde ihn deshalb von cdn.reactive.chat (oder über deinen Proxy) ein, nicht als Kopie.
• Der Kern heißt core.<hash>.js; der Hash stammt aus seinem Inhalt, und jeder Loader kennt genau seinen Kern. So passen Loader und Kern immer zusammen, und ein Kern kann lange zwischengespeichert werden.
• Die Konfiguration (Gestaltung, Texte, Regeln, Touren) kommt bei jedem Verbindungsaufbau vom Server. Änderungen im Konto brauchen keinen neuen Schnipsel; sie wirken nach kurzer Zeit (je nach Einstellung bis zu einer Minute).
• Protokollversion ist 1. Neue Felder kommen hinzu, unbekannte werden ignoriert.
• ReactiveChat.version nennt nach dem Laden die Fassung des Kerns.

Wo du was einstellst

• Im Konto: Aussehen, Texte, Startseite, Regeln, Touren, A/B-Tests, KI-Persona (Anpassung), Team, Wissensdatenbank, Kanäle (Handbuch).
• Am Script-Tag: was je Seite gelten soll (Script-Tag-Referenz).
• Im Seitenskript: Identität, Kontext, Öffnen aus eigenen Elementen (JavaScript-API).
• Auf deinem Server: Signaturen, Kundendaten, Webhooks, API (Identität, Kundendaten, Webhooks, Server-API).

Weiter: Schnellstart