From 8b98de8ccd37b78fd23279f0e8cfefc68cabeaad Mon Sep 17 00:00:00 2001 From: thePR0M3TH3AN <53631862+PR0M3TH3AN@users.noreply.github.com> Date: Wed, 1 Jul 2026 13:18:49 -0400 Subject: [PATCH] [docs] Add P2P/WebTorrent story to the live plans + a BitVid Live advantages section MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Answering "can live use WebTorrent?": classic WebTorrent can't carry live (its infohash needs the complete file), but P2P *live* is real via HLS + peer segment sharing. - live-ingest-plan: new "P2P-assisted playback" section — P2P Media Loader (hls.js-compatible, historically WebTorrent-tracker-based) shares HLS segments over WebRTC to offload origin bandwidth. Gated on real concurrency (DECISION 1's whitelist scope makes live sparse), so v1 = plain hls.js, P2P later. VOD keeps full WebTorrent. - live-publish-plan: new "Why BitVid Live — advantages" section (P2P offload, full-WebTorrent VODs, Nostr-native/no-lock-in, built-in zaps, BYO storage/relays/ self-host, one-canonical-stream+mirrors, archive = first-class video, self- sovereign identity). Playback section cross-references the P2P offload + VOD WebTorrent. Co-Authored-By: Claude Opus 4.8 --- docs/live-ingest-plan.md | 27 ++++++++++++++++++++++++++ docs/live-publish-plan.md | 41 ++++++++++++++++++++++++++++++++++++++- 2 files changed, 67 insertions(+), 1 deletion(-) diff --git a/docs/live-ingest-plan.md b/docs/live-ingest-plan.md index def50e33..3b49d7c1 100644 --- a/docs/live-ingest-plan.md +++ b/docs/live-ingest-plan.md @@ -158,6 +158,33 @@ chat message. Read-only ingest = subscribe by `#a`, render newest. --- +## P2P-assisted playback (future — bitvid's bandwidth edge) + +Q: "Can live use WebTorrent?" **Classic WebTorrent can't carry a *live* stream** — +a torrent's infohash is computed from the *complete* file, and live content +doesn't exist yet. bitvid's WebTorrent is progressive playback of a finished VOD, +not live. **But P2P *live* is real** via a different mechanism: **HLS + peer-to-peer +segment sharing.** hls.js loads segments while a WebRTC swarm shares them among +concurrent viewers, so the origin serves each segment fewer times. + +- **Concrete stack:** [P2P Media Loader](https://github.com/novage/p2p-media-loader) + — hls.js-compatible, and historically used **WebTorrent trackers** for peer + discovery. It's a drop-in segment engine for the Phase-2 hls.js player: the + "WebTorrent-flavored" path for live. +- **bitvid advantage:** every extra concurrent viewer helps *serve* the stream + instead of only consuming origin bandwidth — cutting the Media Node's egress + (the biggest cost/risk of #16c) and matching bitvid's P2P ethos. +- **Why NOT v1:** P2P offload only pays off with **enough concurrent viewers of + the same stream**. DECISION 1 scopes live to whitelisted hosts → likely + low-concurrency/sparse, where a swarm adds complexity + a little latency (on top + of HLS's 6–30s) for little gain. **v1 = plain hls.js; add P2P-assisted HLS + later, gated on real concurrency.** +- **VOD keeps full WebTorrent:** once a stream ends, its recording is an ordinary + bitvid video (complete file → infohash) and gets the normal seed/webseed + treatment (see the publish plan's archive→VOD flow). + +--- + ## Live watch UX best practices (researched July 2026) Unlike shorts, live is a **landscape 16:9, "cinematic"** experience, and the watch diff --git a/docs/live-publish-plan.md b/docs/live-publish-plan.md index eefe61e8..51379b77 100644 --- a/docs/live-publish-plan.md +++ b/docs/live-publish-plan.md @@ -47,6 +47,42 @@ around it. That's Phase 1 and delivers value with zero servers. --- +## Why BitVid Live — advantages over the incumbents + +Lean into what only bitvid can offer; these are the reasons a creator would pick +BitVid Live over zap.stream/Twitch/YouTube. + +- **P2P bandwidth offload (WebTorrent-flavored live).** Classic WebTorrent can't + carry a live stream (its infohash needs the *complete* file), but **P2P-assisted + HLS** can: hls.js + [P2P Media Loader](https://github.com/novage/p2p-media-loader) + (historically WebTorrent-tracker-based) lets concurrent viewers share HLS + segments over WebRTC, so each extra viewer helps *serve* the stream. This + directly cuts the Media Node's egress — the biggest cost of running live infra — + and scales *better* the more popular a stream gets. (Enable when concurrency + warrants; see the ingest plan.) +- **Recordings become full WebTorrent VODs.** The moment a stream ends, its + recording is an ordinary bitvid video: complete file → infohash → **seed + + webseed**, playable P2P + URL like everything else. Twitch/YouTube VODs are + origin-only; bitvid VODs are P2P-distributable and self-hostable. +- **Nostr-native = portable + no lock-in.** The stream is a signed NIP-53 event on + relays, not a row in a platform DB. It's discoverable by *any* Nostr app, the + creator owns it, and it can't be de-platformed by a single company. +- **Zaps built in.** Instant Lightning value-for-value to the host during the + stream (bitvid's existing NWC/zap system) — no ads, no 50% platform cut, no + payout thresholds. +- **Bring-your-own everything.** Own storage (R2/B2/S3/MinIO) for recordings, own + relays, self-hostable Media Node, and an **external-provider-only mode that needs + zero bitvid infra**. No mandatory middleman. +- **One canonical stream, many mirrors.** Restream to YouTube/Twitch/zap.stream + simultaneously while bitvid stays the sovereign home — reach without lock-in. +- **Archive is a first-class video, not a throwaway.** VODs flow into the same + feeds, search, moderation, comments, and zaps as every other bitvid video (the + `s`-tag/info.json/30078 model) — no separate "past broadcasts" ghetto. +- **Self-sovereign identity.** The creator signs; no BitVid account, no bridge + ever holds their key. + +--- + ## Decisions needed > **DECISION 1 — Media hosting model.** Who runs the Media Node? (a) a **managed @@ -223,7 +259,10 @@ This is a specialized upload-modal flow, not a new publishing system. Live: **HLS first** (works everywhere via #16's hls.js), then WebRTC later (DECISION 4), then external-embed fallback. Mirror bitvid's URL-first ethos: -**primary live URL → external mirror → ended recording (VOD).** +**primary live URL → external mirror → ended recording (VOD).** Optional +**P2P-assisted HLS** (P2P Media Loader) offloads Media Node egress once a stream +has enough concurrent viewers — see the ingest plan + Advantages above. The ended +**recording gets full classic WebTorrent** (seed + webseed), like any bitvid video. ---