bitvid/docs/bitvid-bridge-plan.md

BitVid Bridge — cross-platform streaming helper app — Dev Plan

Companion to docs/live-publish-plan.md (#16c) — this expands its Phase 7 (Local Bridge app) into its own plan. The Bridge is the piece that fills the one gap a static web client can't: receiving and routing live media on the creator's machine. Status: FUTURE / exploratory — all design decisions LOCKED (maintainer accepted every recommendation). Sequenced after the #16c Media Node MVP; the Bridge and the server-side Media Node share one codebase (DECISION 7).

Goal (maintainer): a super-simple, easy-to-install, easy-to-use cross-platform app (Windows / macOS / Linux) that makes going live on bitvid turnkey.

---

Core decision

The Bridge is a local media receiver + router, not a Nostr identity holder. It pairs a native media core (receive/record/restream/upload) with an embedded bitvid "Studio" webview that does all Nostr signing. The two stay logically separated inside one app:

BitVid Bridge (one installable app)
├── Native media core  → RTMP/SRT/WHIP ingest, HLS/WebRTC out, record, restream,
│                         S3 upload   (never sees the Nostr key)
└── Embedded Studio webview → bitvid client that signs NIP-53 + publishes VOD
                              (talks to the core over in-app IPC, not localhost HTTP)

Why an embedded webview instead of "the website controls a localhost server": it solves two hard problems at once —

1. No browser↔localhost pain. An HTTPS page calling http://127.0.0.1 hits mixed-content + Private-Network-Access preflight/permission rules. In-app IPC (Tauri commands / Wails bindings) sidesteps all of it.
2. Signing stays in the web layer. The webview is a bitvid client, so it signs exactly as the browser does; the native core never touches the key. This 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 → the public Media Node works for a basic stream. The Bridge earns its place via multi-restream, local recording, hardware/appliance input, and turnkey UX — and later, built-in capture (no OBS).

---

Decisions — ✅ ALL LOCKED

The maintainer accepted every recommendation below; each Recommendation line is now the locked choice. Summary:

#	Decision	Locked
1	App framework	Wails (Go) — one Go binary for desktop + headless node (ties to D7); Tauri was the close alt
2	Control model	Embedded Studio webview primary; optional localhost API later
3	Capture vs receive	Receiver-first MVP; built-in capture as a fast-follow (Phase 5)
4	Webview signer	NIP-46 + encrypted-nsec, NIP-46 preferred
5	Ingest protocols	RTMP for MVP; SRT + WHIP later
6	Recording upload	Bundled rclone (multi-provider, resumable)
7	One codebase, two modes	Yes — desktop Bridge == self-hosted Media Node run --headless
8	Transcode	Pass-through only (-c copy)
9	Code signing	Project owns Apple notarization + Windows cert (budgeted)
10	License / telemetry	Match bitvid; no telemetry by default

D1 resolves to Go/Wails specifically because D7 (one codebase, two modes) is a "yes": a single Go binary serves the desktop Bridge (with UI) and the headless self-hosted Media Node — Go being MediaMTX's own language makes that clean.

DECISION 1 — App framework. Go/Wails vs Tauri vs Electron. *Recommendation: Wails (Go) or Tauri (Rust) — both give a web UI (reuse bitvid's components/tokens) and small binaries; Electron is ~100MB+ and heavy, against "simple install." Slight lean Wails/Go: the media stack is Go-native and MediaMTX is written in Go, so it's one language, one small static binary, trivial cross-compile. Tauri is a very close second with a more mature app-shell

• updater. Pick based on team comfort (Go vs Rust).*

DECISION 2 — Control model. Embedded Studio webview (self-contained app) vs website-drives-localhost-API vs both. Recommendation: embedded webview primary (dodges PNA/mixed-content + keeps signing in the web layer). Optionally expose a localhost API later for people who want to drive it from the bitvid website (with the PNA/CORS work done then).

DECISION 3 — Capture vs receive. MVP receives (OBS/hardware → Bridge) vs push built-in screen/camera capture earlier. Recommendation: receiver-first MVP — works with the OBS/encoders people already have and ships fast. Built-in capture (no OBS) is the "super simple" headline but is effectively a mini-OBS (encoder is hard) → make it a fast-follow phase, not MVP.

DECISION 4 — Signer support in the Bridge webview. Since the webview signs, which login methods? NIP-46 remote signer (no key on device — safest), the encrypted-nsec flow the web app already has (key encrypted on-device), or both. NIP-07 extensions generally aren't available inside an app webview. Recommendation: both NIP-46 + encrypted-nsec, NIP-46 preferred/first. Reuse the web app's existing session/signer code so there's nothing new to audit.

DECISION 5 — Ingest protocols for MVP. RTMP only, or RTMP + SRT + WHIP. Recommendation: RTMP for MVP (universal — OBS/hardware all speak it), add SRT (better over lossy networks) and WHIP (WebRTC ingest, low latency) in a later phase. MediaMTX supports all three, so it's mostly UI/config.

DECISION 6 — Recording upload mechanism. Bundle rclone (one binary, speaks R2/B2/S3/MinIO + resumable) vs a native S3 SDK in the core vs reuse bitvid's browser S3 upload from the webview. Recommendation: rclone bundled as a sidecar — dead-simple multi-provider support + resumable uploads of large recordings, matches the storage providers bitvid already supports. Native SDK only if we want to drop the extra binary.

DECISION 7 — One codebase, two modes? The server-side Media Node (#16c) and the local Bridge are ~the same thing (MediaMTX + session API + upload + restream). Build one codebase that runs headless (Media Node) or with the embedded UI (Bridge)? Recommendation: yes — "self-host the Media Node" (publish-plan DECISION 1b) becomes literally "run the Bridge in --headless mode on a VPS." Big reuse win; steers DECISION 1 toward Go (server + desktop from one Go binary).

DECISION 8 — Transcode. Pass-through (-c copy) only, or offer local transcode profiles? Recommendation: pass-through only (same as the publish plan). Require H.264/AAC in; the Bridge repackages/forwards without re-encoding — keeps CPU low and the app light. Transcoding is a later, opt-in power feature.

DECISION 9 — Code signing + distribution ownership. "Easy install" requires Apple notarization (Developer ID — or macOS Gatekeeper blocks it) and a Windows Authenticode cert (or SmartScreen scares users). Who holds the certs and pays (~$99/yr Apple + Windows cert)? Linux = AppImage + .deb/.rpm (no signing gate). Recommendation: the project owns the certs; budget for them — this is the true cost of "easy to install," not optional.

DECISION 10 — License / telemetry. Open-source license (match bitvid's) and no telemetry by default (opt-in crash reports at most). Recommendation: same license as bitvid; privacy-first, opt-in only.

---

Architecture

BitVid Bridge
├── App shell (Tauri/Rust or Wails/Go)         DECISION 1
│    └── Embedded Studio webview (bitvid client, signs NIP-53/VOD)   DECISION 2,4
├── Native media core
│    ├── MediaMTX (bundled sidecar)   → ingest RTMP/SRT/WHIP, HLS/WebRTC out, record
│    ├── FFmpeg (bundled)             → copy-forward restreams (-c copy)   DECISION 8
│    └── rclone (bundled)             → upload recordings to R2/B2/S3/MinIO  DECISION 6
├── Session/state manager             → LiveSession model, status, tokens
├── IPC bridge                        → webview ↔ core (Tauri cmds / Wails bindings)
└── (optional) localhost API          → for website control, later   DECISION 2

• Media core = a local Media Node. Same engine as the server-side node (#16c), which is why DECISION 7 (one codebase, two modes) is attractive.
• Stream keys / ingest URLs never leave the device and never go into Nostr; the webview only ever publishes the playback URL.
• Status → Nostr: MediaMTX hooks fire input_connected / input_live / input_lost / recording_finalized / upload_complete; the core forwards these to the webview over IPC; the webview signs the corresponding NIP-53 update (planned → live → ended + recording).

---

UX flow (the "super simple" target)

1. Install (signed installer / AppImage).                            DECISION 9
2. Open app → sign in (NIP-46 or encrypted nsec) in the Studio webview. DECISION 4
3. Fill title/thumbnail/tags → "Prepare stream" (publishes status=planned).
4. App shows one of:
   a. RECEIVE MODE: local ingest URL + key to paste into OBS/encoder.  DECISION 3
   b. (later) CAPTURE MODE: pick a screen/window/camera → "Go Live".
5. Encoder connects → core detects input → webview publishes status=live.
6. (optional) toggle restream outputs (YouTube/Twitch/zap.stream).     DECISION 5
7. "End" → status=ended → core finalizes recording → uploads → webview
   offers "Publish recording as a BitVid video" (archive→VOD).

The whole point: one window, sign in, go live, done — and the recording becomes a normal bitvid video automatically.

---

Cross-platform packaging

• Windows: signed .msi/.exe (Authenticode). Auto-update.
• macOS: signed + notarized .dmg (Developer ID) — mandatory. Universal (arm64 + x86_64).
• Linux: AppImage (zero-install portable) + .deb/.rpm; consider Flatpak.
• Bundled binaries per-platform: MediaMTX, FFmpeg, rclone. FFmpeg is the size hog (~50–80MB) — ship a minimal build (only the muxers/protocols we use: flv/rtmp/mpegts/hls/webrtc, aac/h264 passthrough) to keep the installer lean.
• Auto-updater (both Tauri and Wails have one) with signed release artifacts.

---

Phases

• Phase 0 — Shell + media core (foundational). App skeleton (DECISION 1), bundle + supervise MediaMTX, embedded Studio webview, webview↔core IPC, signed dev builds on all three OS. Sign-in works (DECISION 4).
• Phase 1 — Receive → BitVid (the MVP). Local RTMP ingest; copy-forward to the BitVid Media Node; publish planned→live→ended NIP-53 from the webview driven by MediaMTX input hooks. "OBS → Bridge → bitvid, one window."
• 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.
• 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 inside the app (getDisplayMedia/getUserMedia → WebCodecs/FFmpeg). The "super simple" headline: go live with no external encoder.
• Phase 6 — SRT/WHIP ingest + WebRTC low-latency (DECISION 5).
• Phase 7 — Headless "Media Node" mode + hardware / "BitVid Box". Run the same binary headless as the self-hosted Media Node (DECISION 7); harden for appliance/headless use — the seed of a physical device.

---

Engineering rules (invariants)

1. The native core never sees the Nostr key. Only the webview signs.
2. Ingest URLs/keys stay on the device; only playback URLs reach Nostr.
3. Pass-through first — copy H.264/AAC, don't transcode (DECISION 8).
4. Reuse bitvid's web client for the Studio webview (session, signer, publish, upload-modal-style VOD flow) — minimize net-new signing/auth code.
5. Optional, not required — a creator can still stream OBS → public Media Node without the Bridge; the Bridge only adds convenience/power.

---

Risks / watch-items

• Code signing is the real "easy install" cost (DECISION 9). Apple notarization + Windows cert are non-negotiable for a frictionless install and cost money + setup. Budget for them up front.
• Bundle size vs simplicity. MediaMTX + FFmpeg + rclone add up; a minimal FFmpeg build and per-platform packaging keep it reasonable, but it won't be tiny. Trade-off vs "super light."
• Built-in capture is a mini-OBS (DECISION 3/Phase 5). Reliable capture + encode across GPUs/OSes is genuinely hard — don't let it block the receiver MVP.
• Signing during long streams. Same issue as the publish plan (DECISION 2 there): the webview must stay running to sign status updates + heartbeats; handle sleep/crash gracefully (NIP-53 treats no-update-in-~1h as ended).
• Webview signer support. NIP-07 extensions typically aren't present in an app webview → lean on NIP-46 / encrypted-nsec (DECISION 4).
• Encoder compatibility. Pass-through needs H.264/AAC + sane keyframes; detect + warn on incompatible input rather than failing silently.
• Scope creep. This app can sprawl (capture, transcode, appliance). Ship the receiver MVP (Phase 0–1) first; everything else is additive.

---

Sources

• MediaMTX (ingest/playback/record/forward/control API): https://mediamtx.org/docs/kickoff/introduction
• OBS WebSocket (built into OBS 28+): https://obsproject.com/kb/remote-control-guide
• App frameworks: Tauri · Wails (Go) · packaging binaries (MediaMTX, FFmpeg, rclone).
• Companion plans: docs/live-publish-plan.md (#16c, this expands its Phase 7), docs/live-ingest-plan.md (#16, watch side + P2P-assisted HLS).
• bitvid code reused by the Studio webview: session/signer (NIP-46 + encrypted nsec), the upload/publish flow, js/utils/storagePointer.js (s-tag → .info.json) for archive→VOD.