every-channel/every.channel
1
0
Fork 0
Code Releases Activity Actions 2
every.channel/evolution/proposals/ECP-0043-browser-webrtc-bridge.md
every.channel 897e556bea
every.channel: sanitized baseline
2026-02-15 16:17:27 -05:00

1.3 KiB
Raw Blame History

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.