[docs] Add P2P/WebTorrent story to the live plans + a BitVid Live advantages section

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 <[email protected]>

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

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.
 
 ---