[docs] Add three-tier provider spectrum (no-VPS options) + reshape Bridge accordingly

Answering "can we avoid the VPS / use a free service like StreamYard?": yes.

live-publish-plan:
- DECISION 1 broadened into a THREE-TIER provider spectrum (bitvid hosts none):
  (1) platform embed (StreamYard/OBS -> YouTube/Twitch, free, iframe),
  (2) serverless RTMP->HLS API (Livepeer/Mux/Cloudflare, no server, NATIVE HLS) --
      the recommended no-VPS default; Livepeer most aligned,
  (3) self-hosted node (Bridge headless on VPS) -- sovereignty + WebTorrent VOD.
- New "Provider options" table/section; StreamYard clarified as a studio (not a
  CDN). Same NIP-53 event + player across all tiers; only a per-tier playback
  adapter differs. Phase 1 reframed as provider-agnostic (Tiers 1 & 2, no infra).

bitvid-bridge-plan:
- Repositioned as the Tier-3 advanced/sovereignty option (serverless is the no-VPS
  default), not the default on-ramp.
- Added the HYBRID that dissolves the NAT/VPS problem: a local Bridge records
  locally + forwards (outbound) to a Tier-2 serverless provider that serves public
  HLS -> home box needs no public reachability, yet keeps local recording +
  full-WebTorrent VOD. Made serverless a first-class restream preset (Phase 3);
  updated the reachability risk + NAT notes to point at the hybrid.

Co-Authored-By: Claude Opus 4.8 <[email protected]>

docs/bitvid-bridge-plan.md

@@ -38,11 +38,22 @@ it solves two hard problems at once —
    honors the publish plan's Rule 1 ("BitVid signs; Bridge routes") while still
    being one self-contained app.
 
-**When you don't need the Bridge at all:** OBS → an **external provider**
-(zap.stream/YouTube) works for a basic stream (bitvid runs no node — blanket
-rule). The Bridge earns its place by letting a creator **self-host** their own
-node and by multi-restream, local recording, hardware/appliance input, turnkey UX
-— and later, built-in capture (no OBS).
+**Where the Bridge sits (see the publish plan's three-tier provider spectrum):**
+- **Tier 1 (platform embed)** and **Tier 2 (serverless RTMP→HLS: Livepeer/Mux/
+  Cloudflare)** need **no Bridge and no VPS** — Tier 2 is the recommended
+  "no-server, native playback" default. So the Bridge is the **Tier-3 (advanced /
+  full-sovereignty)** option, not the default on-ramp.
+- **The Bridge earns its place** by: no third party at all, **local recording +
+  full-WebTorrent VOD**, multi-restream hub, hardware/appliance input, turnkey UX,
+  and later built-in capture (no OBS).
+
+**Hybrid that avoids a VPS entirely (important):** a **local** Bridge can
+**record locally + restream to a Tier-2 serverless provider** which serves the
+public HLS. The home Bridge then **never needs to be publicly reachable** (no VPS,
+no tunnel/port-forward — it's *outbound* to the provider), yet the creator still
+gets local recording + a full-WebTorrent VOD, and viewers get native HLS. This is
+the sweet spot for most sovereignty-minded creators: **local Bridge for
+record/WebTorrent/control + serverless for reach.**
 
 ---
 
@@ -211,15 +222,20 @@ becomes a normal bitvid video automatically.
   copy-forward from a local Bridge to that reachable node / an external provider
   (never a bitvid-run node). Publish planned→live→ended NIP-53 from the webview via
   MediaMTX input hooks. "OBS → your node → bitvid, one window."
-  *(NAT note: a home-only Bridge can't serve public HLS without a tunnel/
-  port-forward — hence the headless-on-VPS path.)*
+  *(NAT note: a home-only Bridge can't serve public HLS directly → either run
+  headless on a VPS, or use the hybrid: forward to a Tier-2 serverless provider
+  that serves public HLS — see Phase 3.)*
 - **Phase 2 — Record → archive → VOD.** Local recording, finalize, rclone upload
   to the user's storage, manifest → webview publishes a normal bitvid video
   (reuses the `s`-tag/info.json/30078 flow). Optional torrent/webseed for full
   WebTorrent VOD.
 - **Phase 3 — Multi-restream (`FEATURE_LIVE_RESTREAM`).** One input → many outputs
-  (YouTube/Twitch/zap.stream/custom RTMP/SRT), copy-only, per-output status +
-  retry/backoff. Keys stay local; optional public mirror links as `r` tags.
+  (YouTube/Twitch/zap.stream/**serverless providers Livepeer/Mux/Cloudflare**/
+  custom RTMP/SRT), copy-only, per-output status + retry/backoff. Keys stay local;
+  optional public mirror links as `r` tags. **The serverless preset enables the
+  no-VPS hybrid** — a local Bridge records locally + forwards to Livepeer/Mux,
+  which serves the public HLS (the `streaming` URL in the NIP-53 event). This is
+  arguably the flagship Bridge workflow for home creators.
 - **Phase 4 — Turnkey UX + packaging.** One-click go-live, OBS auto-config or
   OBS-WebSocket control, signed/notarized installers + AppImage, auto-update.
 - **Phase 5 — Built-in capture (no OBS).** Screen/window/camera capture + encode
@@ -280,12 +296,14 @@ becomes a normal bitvid video automatically.
 - **Local ingest exposure.** A misconfigured wide bind would expose an unauth'd
   RTMP receiver on the network — default to loopback (invariant 7); require auth
   for any non-loopback bind.
-- **Reachability / NAT (self-hosting reality).** With the blanket rule, the
-  playback origin is the creator's own node — a **home-only Bridge behind NAT
-  can't serve public HLS**. The clean path is running the Bridge **headless on a
-  reachable VPS**; document that, plus optional tunnel/port-forward for the local
-  case. This is the main friction of "self-host everything" and the reason the
-  headless mode (Phase 7 / DECISION 7) matters.
+- **Reachability / NAT (self-hosting reality) — largely solved by the hybrid.** A
+  **home-only Bridge behind NAT can't *serve* public HLS**. Two clean answers:
+  (1) the **hybrid** — the local Bridge *forwards* (outbound) to a Tier-2
+  serverless provider that serves the public HLS, so the home box needs no public
+  reachability at all (recommended for laptops/home); (2) run the Bridge
+  **headless on a reachable VPS** for full self-hosting (no third party). Only (2)
+  needs a VPS; document both. This is why headless mode (Phase 7 / DECISION 7) and
+  restream-to-serverless (Phase 3 preset) both matter.
 
 ---
 

docs/live-publish-plan.md

@@ -35,9 +35,36 @@ Media Node / Bridge    = RTMP/SRT/WHIP ingest, HLS/WebRTC output, recording,
 ```
 
 This keeps BitVid's architecture intact while adding broadcast. Crucially,
-**external-provider-only mode needs no BitVid infrastructure at all** — a creator
-streams to zap.stream/YouTube/Twitch and BitVid just publishes the NIP-53 event
-around it. That's Phase 1 and delivers value with zero servers.
+**most of these modes need no bitvid infrastructure at all** — see the three-tier
+spectrum next.
+
+---
+
+## Provider options — three tiers (bitvid hosts none of them)
+
+The creator chooses who receives their media; bitvid only ever **publishes the
+resulting `streaming` URL and plays it**. A VPS is only the *most sovereign* tier,
+not a requirement — most creators never run a server.
+
+| Tier | Setup / cost | Playback in bitvid | Trade-off | bitvid work |
+|------|--------------|--------------------|-----------|-------------|
+| **1. Platform embed** — StreamYard/OBS → YouTube/Twitch | free, **zero infra** | their **iframe** embed | their rules/ads; no native playback, no P2P/WebTorrent | external-embed adapter |
+| **2. Serverless RTMP→HLS API** — Livepeer / Mux / Cloudflare Stream | ~free–cheap, **no server** | **native HLS** (+ P2P-assist possible) | small cost at scale; a 3rd-party account | native HLS (from #16) |
+| **3. Self-hosted node** — the Bridge run headless on a VPS | most effort/cost | native HLS | full **sovereignty + WebTorrent VOD + restream** | native HLS + Bridge |
+
+- **Recommended default "no-VPS but native": Tier 2, Livepeer** — decentralized,
+  crypto-native, cheapest-aligned; the creator points OBS/StreamYard at Livepeer's
+  RTMP ingest and pastes the HLS URL into bitvid. [Mux](https://www.mux.com/live)
+  (free delivery allotment; live needs a paid quality tier) and
+  [Cloudflare Stream](https://developers.cloudflare.com/stream/pricing/) (free
+  ingest/encoding, cheap delivery) are alternatives.
+- **StreamYard is a studio, not a CDN** — it broadcasts *out* to
+  YouTube/Twitch/custom-RTMP (custom RTMP is paid), so with bitvid it's a Tier-1
+  encoder feeding YouTube/Twitch, or a Tier-2/3 encoder feeding a serverless
+  API / your node.
+- **The same NIP-53 event + player serve all three tiers** — the only per-tier
+  code is the playback adapter (external embed vs native HLS). So supporting the
+  spectrum is cheap, and the VPS/Bridge is the *advanced* tier, not the default.
 
 ---
 
@@ -94,13 +121,21 @@ BitVid Live over zap.stream/Twitch/YouTube.
 
 ## Decisions needed
 
-> **DECISION 1 — Media hosting model. ✅ LOCKED by the blanket rule: self-host OR
-> external-provider only — NO bitvid-operated node, ever.** Two supported paths:
-> **(c) external-provider-only** (no node — stream to zap.stream/YouTube/Twitch,
-> bitvid just publishes the NIP-53 event; **ships first**, zero infra) and
-> **(b) self-hosted** (the creator runs their own Media Node = the Bridge headless;
-> most aligned). The managed-BitVid-node option is **removed**. Order: ship (c)
-> first, then ship (b) as the Bridge/headless path.
+> **DECISION 1 — Media hosting model. ✅ LOCKED by the blanket rule: a three-tier
+> provider spectrum — bitvid hosts NONE of them.** The creator picks who receives
+> their media; bitvid just publishes the resulting `streaming` URL. **A VPS is only
+> the *most sovereign* tier, not a requirement.** See "Provider options" below:
+> 1. **Platform embed** (StreamYard/OBS → YouTube/Twitch) — free, zero infra;
+>    bitvid embeds their player. **Ships first (Phase 1).**
+> 2. **Serverless RTMP→HLS API** (Livepeer / Mux / Cloudflare Stream) — no server
+>    to run; the creator gets a real HLS URL bitvid plays **natively**. The
+>    recommended "no-VPS but native" default. **Livepeer** is the most aligned.
+> 3. **Self-hosted node** (the Bridge run headless on a VPS) — full sovereignty +
+>    WebTorrent VOD + restream control; most effort. The advanced tier.
+>
+> The managed-BitVid-node option is **removed**. bitvid's job (publish the event,
+> play the `streaming` URL) is **identical across all three** — the only code
+> difference is a per-tier playback adapter (external embed vs native HLS).
 
 > **DECISION 2 — Signing during a live stream. ✅ LOCKED: A for MVP, B (NIP-46)
 > later; D removed by the blanket rule.** The node must NOT hold the creator's key.
@@ -306,10 +341,13 @@ has enough concurrent viewers — see the ingest plan + Advantages above. The en
 - **Phase 0 — Flags + schema (small).** `FEATURE_LIVE_PUBLISH/BRIDGE/RESTREAM`;
   30311/1311 **builders** + `updateLiveStreamStatusEvent` + `getLiveAddress`
   (coordinate with #16's parsers); `docs/live.md`; schema-doc update; unit tests.
-- **Phase 1 — External-provider publishing (small; NO infra).** "Create Live
-  Stream" modal: title/summary/thumbnail/tags/starts + a paste-in `streaming` URL;
-  publish planned→live→ended; chat + zaps against the live address (reusing #16).
-  *This is BitVid Live v0 and needs zero servers — DECISION 1(c).*
+- **Phase 1 — Provider-agnostic publishing (small; NO infra — Tiers 1 & 2).**
+  "Create Live Stream" modal: title/summary/thumbnail/tags/starts + a paste-in
+  `streaming` URL / platform link; publish planned→live→ended; chat + zaps against
+  the live address (reusing #16). Playback adapter picks **external embed**
+  (Tier 1: YouTube/Twitch) or **native HLS** (Tier 2: Livepeer/Mux/Cloudflare).
+  *This is BitVid Live v0, needs zero servers, and covers the recommended no-VPS
+  path (Tier 2 / Livepeer).*
 - **Phase 2 — Bridge API client + mock backend (medium).** `liveBridgeClient`,
   Pair-Bridge UI, mocked `/sessions`, setup wizard, status dashboard,
   recording-ready flow — builds the client contract before real infra exists.