every.channel/evolution/proposals/ECP-0052-direct-subscribe-cli.md

ECP-0052: Direct Subscribe CLI (WebRTC Directory Mode)

Status: Draft

Goal

Allow a non-Tauri node to subscribe to a direct-publish stream using the same WebRTC data-channel protocol used by the website, so we can:

• validate end-to-end connectivity (publisher -> every.channel bootstrap -> subscriber),
• capture a short proof artifact (CMAF fragments and/or an .mp4 remux),
• debug issues without opening a browser.

Non-Goals

• This is not MoQ transport.
• This is not a long-lived relay/mesh node.
• This does not implement signatures / merkle manifests / anti-junk policy.

Proposal

Add a new ec-node direct-subscribe command that:

1. Locates an offer either:
   • from --offer (an every.channel://direct?c=... link), or
   • from --directory-url + --stream-id (fetch /api/directory, find matching stream_id).
2. Creates a WebRTC answerer connection using just-webrtc (SimpleRemotePeerConnection).
3. If operating via directory:
   • POSTs the answer to /api/answer with { stream_id, answer }.
4. Receives object frames on the data channel, decodes via ec-moq::decode_object_frame, and writes CMAF artifacts to disk:
   • cmaf/init.mp4
   • cmaf/segment_000000.m4s ... cmaf/segment_XXXXXX.m4s
   • cmaf/index.m3u8 (VOD playlist, #EXT-X-ENDLIST)
5. Optionally remuxes the captured playlist to an .mp4 using ffmpeg -c copy.

Why Now

We need a reproducible harness to verify:

• a remote publisher (e.g. a node near an HDHomeRun) can be watched from a distant network,
• directory announcement/answer flow works without manual copy/paste,
• received CMAF fragments are valid enough to remux and play.

Rollout / Reversibility

• Additive CLI only; no protocol changes.
• Can be removed without affecting existing publish/web paths.