XScaler-Protokoll

XScaler ist das öffentliche Preflight-Protokoll, mit dem XTend-Hosts entscheiden, ob eine Remote Surface, ein SSR-Adapter und ein XTension-Deployment in einen Runtime-Slot skaliert werden dürfen, bevor Remote-Code ausgeführt wird.

Schichtgrenze

XScaler ist in zwei Schichten mit getrennten Verantwortlichkeiten aufgeteilt:

1. XScaler Preflight trifft eine statische Annahme-/Ablehnungsentscheidung, bevor ein Remote Bundle, eine SSR-Adapter-Erweiterung oder XTension-Code ausgeführt wird. Preflight vergleicht Host-Capabilities, Manifest-Fakten, Integrity-Metadaten, Fallback-Verfügbarkeit, Lane-Platzierung und Policy-Anforderungen und liefert danach den akzeptierten Plan oder den Ablehnungsgrund. Preflight ist bewusst frei von Seiteneffekten: Es öffnet keine Flight-Session, streamt keine UI, führt keine Actions aus und materialisiert keine Surface.
2. XScaler ATC (Air Traffic Control) besitzt nach akzeptiertem Preflight die Runtime-Flight-Session. ATC koordiniert Client/Server-Kommunikation, Session-IDs, die Übergabe vom akzeptierten Plan an den Runtime-Host, Lifecycle-Übergänge, Abbruch, Fallback-Aktivierung und Diagnostics. ATC kann orchestrieren, wann eine Remote Surface einen Slot belegt oder verlässt, macht den RMT Kernel aber weiterhin nicht zu einem privaten Remote-Code-Executor.

Nachgelagerte Schichten halten dieselbe Grenze ein. Die Maraca Runtime verarbeitet akzeptierte Streams im Client, führt deklarierte Actions aus und materialisiert Surfaces. XSurface Shard Server Schichten können serverseitige Remote Surfaces orchestrieren. Generische Server-Endpunkte bleiben der Fallback-Pfad, wenn keine Remote Surface Orchestration verfügbar ist. RMT Kernel/Fabric behält Scheduling, Lanes, Diagnostics und Policy-Auswertung, führt aber niemals private Remote-Ausführung aus.

Schemas

XScaler-Fixtures und Übergabe-Records verwenden fünf stabile Schema-Namen:

• xtend.xscaler.preflight-request.v1 für Capability-Anfragen des Hosts.
• xtend.xscaler.preflight-response.v1 für Annahme, Ablehnung und erforderliche Folge-Anker.
• xtend.xscaler.remote-surface-plan.v1 für Owner, Origin, Integrity, Fallback und Lane-Platzierung.
• xtend.xscaler.xtension-deployment.v1 für gatebare XTension-Rollout-Metadaten.
• xtend.xscaler.atc-handoff.v1 für ATC-kompatible Session-, Lifecycle-, Fallback- und Runtime-Boundary-Fakten.

Preflight-Flow

1. Der Host erzeugt einen xscaler-preflight-request mit SSR- und XTension-Capabilities.
2. Tooling liefert eine xscaler-preflight-response, die festhält, ob die Surface akzeptiert wird.
3. Akzeptierte Surfaces hängen einen xscaler-remote-surface-plan und bei Bedarf ein xscaler-xtension-deployment an.
4. ATC-kompatible Server emittieren eine xscaler-atc-handoff-Shape mit Session, Signal, Lifecycle und Runtime-Boundary-Fakten.

Remote-Surface-Plan

Der Plan spiegelt den RMT-Remote-Surface-Vertrag: Owner, Origin, Integrity, Fallback-Surface und Lane-Ziel sind statische Fakten. XScaler lädt oder führt während der Validierung kein Remote-Bundle aus.

Integrität des Remote-Adapter-Artefakts

Der Browser-Loader akzeptiert nur eigenständige Modul-Bundles. Alle ausführbaren Abhängigkeiten müssen vor Freigabe des SRI-Digests eingebündelt werden. Statische Imports, dynamische Imports (auch verzögert oder mit berechnetem Pfad) und Re-Exports anderer Module werden vor dem Erzeugen eines Script-Elements abgelehnt. Import-Text in Kommentaren oder Strings bleibt zulässig; die Prüfung nutzt einen JavaScript-Parser.

Der Loader lädt ohne Credentials und ohne Redirects, begrenzt die Antwort standardmäßig auf 1 MiB und 15 Sekunden, prüft die Bytes gegen den freigegebenen Digest und parst diese verifizierten Bytes. Das native Modul-Script prüft beim Ausführungsabruf nochmals SRI. Dadurch kann auch ein zwischen Prüfung und Ausführung verändertes Root-Modul keine anderen Bytes einschleusen. Ein unverändertes Root-Modul mit veränderter Import-Abhängigkeit wird vollständig abgelehnt; der einzelne Digest verspricht keine transitive Browser-SRI.

Eigene Host-Loader müssen dieselbe Grenze erzwingen und closedGraphIntegrity: true deklarieren. Dies ist eine vertrauenswürdige Host-Fähigkeit, kein Provider-Nachweis. Der Vertrag ist keine Sandbox und verbietet nicht sämtliche anderen APIs zum Nachladen von Code. CSP-Grenzen für Evaluation, Scripts und Worker bleiben notwendig; Provider-Code ohne Seitenberechtigung benötigt eine isolierte Origin/Sandbox. Der Regressionstest zu csf_1e84f759699fec8ea5bf83f1 steht in tests/security/xscaler.test.cjs.

SSR-Kompatibilität

SSR-Adapter müssen XScaler als reinen Preflight-Vertrag behandeln. Ein kompatibler Plan setzt networkDuringRender auf false, hält Remote-Ausführung aus dem Server-Render-Pfad heraus und hydriert erst nach akzeptierter Preflight-Response.

XTensions-Deployment

XTensions können XScaler verwenden, um Framework-Inseln hinter einem gegateten Deployment-Record auszurollen. Deployment-Records müssen XTension, Surface, Rollout-Strategie und SSR-Hydration benennen.

ATC-Übergabe

Eine ATC-Übergabe transportiert akzeptierte Surface, Session-ID, Übergabesignal, Lifecycle-State und Runtime Boundary. Kompatible Übergaben halten remoteRuntimeExecution und kernelRemoteExecution auf false.

Fixtures

Die minimale Fixture-Familie liegt unter tests/rmt/fixtures/xscaler/ und deckt Preflight-Request, Preflight-Response, Remote-Surface-Plan, XTension-Deployment und ATC-Kompatibilitäts-Records ab.

Weiterführend

Die Hydration Policies erklären, wann XScaler-Preflight-Daten Resume- oder Hydrate-Verhalten beeinflussen. Verwandter Artikel