Spec proposal: OVOS-BRIDGE-1 — Bus Bridge and Opaque Relay

Proposal for OVOS-BRIDGE-1, the bus bridge and opaque relay specification.

Problem

Bridge implementations (HiveMind gateway, any inbound message fan-in) have no normative contract. Source stamping, session preservation, routing signals, multi-deployment topologies, and satellite skill registration are all implementation-defined.

Proposal

The bridge carries minimal normative weight — most of the spec documents emergent patterns from composing existing specs at a bus boundary. The two core MUSTs are:

1. Stamp a unique source on every inbound message
2. Preserve the context.session object during relay

Everything else — policy injection, pipeline overrides, topology patterns, satellite skill registration — emerges from composing MSG-1 + SESSION-1/2 + PIPELINE-1 + TRANSFORM-1 + INTENT-4 at the bus boundary.

Key design decisions

• Destination-based routing. .reply() sets destination = original source; two participants sharing session_id: "default" are distinguished by destination alone
• site_id owned by BRIDGE-1. Bridge is the natural assignment point (geolocation, home-automation area names); client MAY report, bridge MAY override
• Two session-preservation modes. Relaying (spec-aware clients: transparent carrier) vs. managing (opaque clients: bridge owns session lifecycle)
• Satellite skill registration is transparent. INTENT-4 §11 session-scoped registration + existing destination routing; no new protocol needed
• Dialog transformers run on the satellite. Audio-output layer is local; session carries transformer preferences back in ovos.utterance.speak

PR

PR #43

Review the OVOS-BRIDGE-1 proposal and PR #43 first, then compare its decisions with MSG-1, SESSION-1/2, PIPELINE-1, TRANSFORM-1, and INTENT-4. Done means the bridge contract and its two MUSTs, routing, session modes, site ownership, registration, and transformer behavior are resolved in the specification.