Whitepaper · Rebuild Edition
dStream Protocol Whitepaper
This document describes the architecture, economic rails, and security boundaries of the currently shipped dStream runtime.
Abstract
dStream is a decentralized live-streaming protocol in which identity and coordination are relay-native (Nostr), media transport is replaceable (WHIP/WHEP/HLS), and payment rails remain user-owned (wallet-driven). The protocol separates coordination from transport so creators keep portable identity and audience continuity across infrastructure changes.
1. System Model
Control plane (Nostr): stream announce (`kind 30311`), presence (`30312`), moderation/roles (`30313`), chat (`1`), and private coordination (`4` / `20004`).
Media plane: broadcaster publishes through WHIP; playback resolves through WHEP first and HLS fallback.
Assist plane: P2P assist can exchange HLS bytes over WebRTC datachannels under host policy constraints.
Value plane: Monero verification uses wallet-rpc sessions; additional assets are direct payout rails with wallet URI integration.
2. Canonical Identity and Routing
- Canonical key tuple: `(pubkeyHex, streamId)`.
- User-visible route uses NIP-19 (`npub`) and backend converts to hex.
- Watch route: `/watch/:npub/:streamId` with compatibility for hex pubkeys.
- Origin stream id rule: `${pubkeyHex}--${streamId}`.
3. Broadcast and Playback Flows
- Broadcaster captures camera/screen and publishes via WHIP.
- Broadcast page publishes a replaceable live announce event (`kind 30311`).
- Watch page resolves announce, builds preferred playback URL, and attempts WHEP.
- If WHEP is unavailable, playback fails over to HLS.
- P2P assist path activates only when host mode allows and stake requirements are satisfied.
p2p_economy: active rebroadcast set + queue thresholding; stake can gate assist role.host_only: direct origin serving only; no rebroadcast queue incentives.
4. Economic Rails and Wallet Integration
- Tip/session APIs support verified Monero transfer detection and confirmation status.
- Stake/session APIs support required stake checks and refund settlement route.
- Escrow-v3 APIs provide multisig coordination steps for participant/coordinator exchange.
- Additional assets (ETH/BTC/USDT/XRP/USDC/SOL/TRX/DOGE/BCH/ADA/PEPE) are payout methods with URI helpers.
- Wallet preferences are configured per asset in Settings and surfaced on watch page.
Trust boundary: this implementation coordinates escrow policy in app/origin services; it is not a trustless generalized on-chain VM.
5. Integrity, Moderation, and Safety
- Signed integrity manifests can be checked client-side with explicit verified/tampered state.
- Relay moderation events and local controls enforce mute/block/role policy in chat surfaces.
- NIP-05 policy can be required for elevated moderation and role management actions.
- Presence/assist state is advisory and does not replace origin access controls.
- Liability boundary: each node operator is responsible for content they publish or relay; dStream does not exercise editorial control over third-party broadcasts.
6. API and Operations Profile
Runtime includes WHIP/WHEP/HLS proxy routes, payment catalog/validation endpoints, Monero verified tip/stake/escrow APIs, and operator scripts for hardening, runtime smoke checks, backup, and health monitoring.
Production gate is enforced before deploy and should fail closed when required runtime dependencies are missing.
7. Current Implementation Surface
Implemented runtime surface includes broadcast studio, watch playback, relay-based discovery, profiles/inbox/guild flows, moderation controls, analytics, wallet integrations, and deploy-time production gates.