# ECP-0043: Browser Participation via WebRTC DataChannel Bridge (Exploration)

## Why

Browsers cannot currently join the same QUIC-based transport stack directly (constraints around raw QUIC, UDP, and custom discovery). We still want web viewers and lightweight web relays to participate without central servers.

## Proposal

- Add an optional "browser bridge" transport implemented with WebRTC DataChannels.
- A native node can act as a bridge:
  - It speaks the native transport with other peers.
  - It speaks WebRTC DataChannel with browsers.
  - It forwards encrypted objects/manifests between the two worlds.
- Signaling starts as manual copy/paste (offer/answer) to avoid a required central service.
  - Later: directory-assisted rendezvous can be layered without changing the data plane.

## Scope (initial)

- Watch-only in browser (receive + play CMAF) using DataChannel + MSE.
- Native bridge CLI command to generate offers / accept answers.

## Open Questions

- How to represent reachability in the directory without exposing protocol terms.
- Rate limits and anti-junk enforcement at the bridge boundary.
- Best-effort determinism when browsers become publishers (likely not guaranteed).

## Reversibility

High. WebRTC bridge is an adapter layer; core protocol stays unchanged.