every.channel: sanitized baseline

evolution/proposals/ECP-0053-direct-wire-framing.md

@@ -0,0 +1,49 @@
+# ECP-0053: Direct WebRTC Wire Framing (Chunked Frames)
+
+Status: Draft
+
+## Problem
+
+`direct-publish` currently sends each CMAF object (init or `.m4s` fragment) as a single WebRTC
+data-channel message (`encode_object_frame(meta, data)`).
+
+Real OTA CMAF fragments routinely exceed typical data-channel maximum message sizes, causing
+runtime failure like:
+
+- `Error: outbound packet larger than maximum message size`
+
+This blocks real-world HDHomeRun end-to-end streaming via `https://every.channel`.
+
+## Goal
+
+Make direct WebRTC transport robust by supporting large objects while keeping:
+
+- ordered delivery,
+- simple decoding in the website and CLI,
+- no additional servers beyond the existing bootstrap API.
+
+## Proposal
+
+Define a minimal application-layer framing over WebRTC data-channel messages:
+
+- Each data-channel message begins with a 1-byte tag:
+  - `0x00`: legacy "whole object frame in one message" (optional compatibility)
+  - `0x01`: stream-chunk bytes (new default)
+- In `0x01` mode, bytes carry a length-prefixed stream:
+  - `[u32_be length][frame bytes]` repeated
+  - `frame bytes` are exactly the existing `encode_object_frame(meta, data)` output
+- Publishers MUST:
+  - use `0x01` mode,
+  - split the stream into safe message payloads (e.g. 16 KiB chunks)
+- Subscribers SHOULD:
+  - accept both `0x01` and `0x00` to ease rollout.
+
+## Rollout
+
+- Update `ec-node direct-publish`, the website receiver, and `ec-node direct-subscribe`.
+- Redeploy static site assets; bootstrap API unchanged.
+
+## Reversibility
+
+- The change is localized to `direct-*` and can be removed or replaced without touching MoQ.
+