every-channel/every.channel
1
0
Fork 0
Code Releases Activity Actions 2

every.channel: sanitized baseline

Browse source
This commit is contained in:
every.channel 2026-02-15 16:17:27 -05:00
commit 897e556bea
No known key found for this signature in database
258 changed files with 74298 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

31
evolution/proposals/ECP-0043-browser-webrtc-bridge.md Normal file
View file

@ -0,0 +1,31 @@
# 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.