Aeion Bridge Module Technical Specifications

A connection manager on the cloud side owns the Bridge WebSocket session for your tenant. It handles discovery (configured URL first, then mDNS/SSDP on the local network), the initial handshake, exponential-backoff reconnection (5s → 10s → 20s → up to 60s, 10 attempts before giving up), and dispatching MCP tool calls to whichever Bridge client is currently connected. If no Bridge client is connected, cloud-only operations continue unaffected and Bridge-dependent calls return a clear "not connected" response.

MCP tool registration:

```typescript // When a Bridge client connects, it registers its available tools: { "method": "tools/register", "params": { "tools": [ { "name": "compute.image.generate", "schema": { ... } }, { "name": "compute.tts.generate", "schema": { ... } }, { "name": "docker.logs", "schema": { ... } }, // ... 50+ tools total ] } }

// Cloud calls a tool the same way it calls any MCP tool: { "method": "tools/call", "params": { "name": "compute.image.generate", "arguments": { "prompt": "...", "model": "flux-schnell" } } } // → Forwarded to the Bridge client over WebSocket // → Executed locally, on your hardware // → Result returned to cloud ```

All image generation is exposed as Bridge MCP tools — compute.image.generate (text-to-image and img2img), compute.image.edit (inpainting), compute.image.upscale, and compute.image.models for listing installed models.

Generation parameters: prompt, negativePrompt, model ("flux-schnell" / "sdxl-turbo" / "sd-3.5" / etc.), width / height (default 1024), steps (default 20), cfgScale (default 7.5), seed, batchSize (default 1), plus optional sourceImage + strength for img2img, controlNet (canny / depth / pose / scribble / tile guidance with guidanceStart / guidanceEnd), and lora (one or more LoRA models with a weight 0.0–2.0).

Result shape: a list of base64-encoded images, the model used, generation time, seed, steps, and cfgScale.

img2img example:

typescript // Transform product photo to a different style const result = await bridge.call("compute.image.generate", { prompt: "professional studio photography, white background, soft lighting", negativePrompt: "blurry, noise, distorted", model: "flux-schnell", width: 1024, height: 1024, steps: 25, cfgScale: 7.5, // img2img mode: sourceImage: base64ProductPhoto, strength: 0.7, // 70% influenced by prompt // ControlNet for pose preservation: controlNet: { model: "canny", image: base64EdgeMap, guidanceStart: 0.0, guidanceEnd: 0.8, }, });

Inpainting example (parameters: image, mask — white = keep, black = regenerate — prompt, model, strength, default 0.75):

typescript const inpainted = await bridge.call("compute.image.edit", { image: base64ProductPhoto, mask: base64MaskOfBackground, // White = keep product, Black = new background prompt: "dreamy outdoor garden background, bokeh lights", model: "flux-schnell", strength: 0.8, });

Upscaling (parameters: image, scaleFactor — 2 or 4 — model, default "real-esrgan"):

typescript const upscaled = await bridge.call("compute.image.upscale", { image: base64Generated1024, scaleFactor: 4, // 1024 → 4096 model: "real-esrgan", });

Model listing:

typescript const models = await bridge.call("compute.image.models", {}); // → [{ id: "flux-schnell", name: "FLUX.1 [schnell]", type: "txt2img", vramRequired: 8, installed: true, ... }]

TTS is exposed as Bridge MCP tools — compute.tts.generate (generate speech), compute.tts.stream (progressive streaming for real-time use), compute.tts.models (list voices/models), compute.tts.clone (voice cloning), and model management tools for installing/removing local voice models.

Request parameters: text (up to 10,000 characters), voice (voice ID), model ("kokoro" / "bark" / "f5-tts"), speed (0.5–2.0), format ("mp3" / "wav" / "ogg"), sampleRate (24000 / 44100 / 48000). Result: base64-encoded audio, duration, format, model, voice, and text length. Voices carry an id, display name, language, gender, and provider.

TTS streaming (for real-time):

```typescript // For applications that need progressive audio output const stream = await bridge.call("compute.tts.stream", { text: "Welcome to Acme Corp. Your call may be recorded for quality assurance.", model: "kokoro", format: "mp3", speed: 1.0, });

// stream is a ReadableStream<Uint8Array> // Can pipe directly to audio element or WebSocket

// Or use the TTS route directly: POST /bridge/tts/stream { "voice": "en-US-Neural2-F", "model": "kokoro" } // → Starts a streaming TTS session; response carries a session handle ```

Native capture is exposed as Bridge MCP tools: screen capture (source: screen or a specific window/display, format png/jpg/webp, quality, cursor inclusion), camera capture, microphone recording, and system info (platform, architecture, CPU count, total/free memory, attached GPUs with VRAM and compute capability, OS version, hostname, uptime).

Behind the Bridge admin views, the platform keeps three records per tenant:

• Device registry — every Bridge client that has ever connected: name, type (computer / server / IoT / printer / scanner / camera), online/offline/error status, advertised capabilities, first/last seen, client version, network identity (IP, hostname, MAC where available), OS, and attached GPU (name, VRAM, compute capability).
• Audit log — every MCP tool call made through Bridge: which device, which user, which tool, a redacted copy of the arguments, success/error/timeout status, execution time, and a timestamp. This is what powers the compliance exports described below.
• Model installations — what's installed on each device: model type (image / TTS / video / audio / 3D / code), model id and name, install status, size, VRAM required, install/last-used timestamps, and version.

API key scopes:

typescript { "type": "bridge_client", "tenantId": "tenant_acme", "scopes": [ "bridge:read", // List devices, capabilities "bridge:write", // Configure devices "ai:generate", // Image generation, TTS, video "docker:manage", // Docker operations "terminal:execute", // Shell commands "git:manage", // Git operations "files:local", // Local file access "media:capture", // Screen, camera, mic ], "deviceId": "bridge_device_id", "expiresAt": "2027-05-11", }

Per-tool authorization: every Bridge tool is mapped to exactly one required scope — image/TTS/video generation tools require ai:generate, Docker tools require docker:manage, terminal execution requires terminal:execute, Git tools require git:manage, media capture requires media:capture, and read-only status tools require bridge:read. A tool call is rejected outright if it isn't in that map (unknown tool) or if the calling key's scopes don't include the required one.