31 lines
1.3 KiB
Markdown
31 lines
1.3 KiB
Markdown
# 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.
|
|
|