83 lines
5.1 KiB
Markdown
83 lines
5.1 KiB
Markdown
|
# IndeeHub distributed viewing: protocol review
|
||
|
|
|
||
|
|
Status: preliminary design, 2026-10-05. Not implemented or qualified. Reconcile
|
||
|
|
with actual IndeeHub source before selecting the final event/API contract.
|
||
|
|
|
||
|
|
## Updated constraints
|
||
|
|
|
||
|
|
The older `phase4-streaming-ecash-plan.md` mixes producer content sales with
|
||
|
|
bandwidth resale and an optional iroh swarm. Its implementation assertions are
|
||
|
|
historical. The operator now requires FIPS for inter-node media bytes, producer
|
||
|
|
payments, timed viewing, and an Archipelago catalog across instances. A successful
|
||
|
|
bandwidth payment alone must not unlock a producer's protected film.
|
||
|
|
|
||
|
|
The old document also describes a fail-open paid-serving path. Audit the current
|
||
|
|
implementation; never adopt fail-open behavior for paid media or key delivery.
|
||
|
|
Keep free software updates outside any paid-content gate.
|
||
|
|
|
||
|
|
## Primary specifications checked
|
||
|
|
|
||
|
|
- [NIP-71 video events](https://github.com/nostr-protocol/nips/blob/master/71.md):
|
||
|
|
defines ordinary and addressable video metadata, including variants. Evaluate
|
||
|
|
addressable normal-video events for stable film identity and metadata updates.
|
||
|
|
This is a draft optional specification, not a complete rental/access protocol.
|
||
|
|
- [NIP-94 file metadata](https://github.com/nostr-protocol/nips/blob/master/94.md):
|
||
|
|
describes file hashes, MIME types, sizes and locations. Reuse compatible fields
|
||
|
|
rather than inventing incompatible meanings for standard tags.
|
||
|
|
- [Blossom BUD-01](https://github.com/hzrd149/blossom/blob/master/buds/01.md):
|
||
|
|
specifies SHA256-addressed HTTP blob retrieval. Its public cross-origin server
|
||
|
|
conventions must not be copied onto dashboard/RPC authentication boundaries.
|
||
|
|
Hash addressing can complement a FIPS-backed gateway; Blossom alone does not
|
||
|
|
establish payment or timed viewing rights.
|
||
|
|
- [Cashu NUT-18](https://github.com/cashubtc/nuts/blob/main/18.md): receiver requests
|
||
|
|
can describe amount, unit, accepted mints and token delivery. Reconcile supported
|
||
|
|
mint preferences/methods with our deployed wallets, not just the latest schema.
|
||
|
|
- [NUT-04](https://github.com/cashubtc/nuts/blob/main/04.md) and
|
||
|
|
[NUT-23](https://github.com/cashubtc/nuts/blob/main/23.md): verify current mint
|
||
|
|
quote/payment accounting and BOLT11 behavior against supported mints. Keep quote
|
||
|
|
identifiers private. Successful invoice payment and successful token issuance
|
||
|
|
are distinct recovery steps; never repeat payment to recover an issuance reply.
|
||
|
|
|
||
|
|
These are source/specification findings. Compatibility with existing clients and
|
||
|
|
mints remains to be tested. Pin specification revisions when implementing so a
|
||
|
|
moving document cannot silently change the wire contract.
|
||
|
|
|
||
|
|
## Proposed separation of responsibilities
|
||
|
|
|
||
|
|
1. **Discovery:** publisher-authorized signed metadata; stable film/version ID,
|
||
|
|
public title/artwork/teaser and explicit supported paid-content extension.
|
||
|
|
Deduplicate, reconcile updates/deletions and recover missed events. Do not put
|
||
|
|
private viewing keys, receipts, quotes or wallet credentials on public relays.
|
||
|
|
2. **Producer offer and settlement:** reuse recipient-capability negotiation from
|
||
|
|
file purchases. Bind amount, recipient, content version and duration to one
|
||
|
|
durable purchase ID. Verify settlement at the seller before issuing access.
|
||
|
|
Support the existing Lightning-to-ecash-address flow without requiring LND.
|
||
|
|
3. **Viewing entitlement:** a versioned authenticated grant with content, buyer,
|
||
|
|
validity and replay rules. This is application-specific until interoperability
|
||
|
|
is demonstrated; do not present it as defined by the metadata/payment NIPs.
|
||
|
|
4. **Playback gateway:** browser/companion use normal authenticated media requests
|
||
|
|
to their node. The node obtains protected segments over FIPS and verifies
|
||
|
|
content integrity and entitlement. Seek/retry/resume reuse the purchase.
|
||
|
|
5. **Caching:** peers may cache authorized ciphertext. Key delivery and subsequent
|
||
|
|
segment access remain gated. Already delivered plaintext or keys cannot be
|
||
|
|
made uncopyable or retroactively revoked; do not promise DRM guarantees.
|
||
|
|
|
||
|
|
No silent media fallback to Tor/LAN/iroh satisfies the operator's FIPS requirement.
|
||
|
|
If FIPS is unavailable, retain paid ownership and explain retry/recovery rather
|
||
|
|
than charge again. Separate routing diagnostics from normal playback controls.
|
||
|
|
|
||
|
|
## Decisions and proofs required before publishing the test film
|
||
|
|
|
||
|
|
Identify the exact Yaya Cloud video, preserve its original and obtain the intended
|
||
|
|
price and viewing-window semantics. Define activation versus expiry, clock skew,
|
||
|
|
multiple devices, publisher outage, refund policy and content-version replacement.
|
||
|
|
Use isolated/regtest funds for automated tests; new real payments require a bounded
|
||
|
|
amount authorization. Publish no unrelated Cloud file.
|
||
|
|
|
||
|
|
Qualification must cover settlement with lost replies, duplicate payment callbacks,
|
||
|
|
wrong mint/recipient/content, denied keys, expired grants, FIPS outage and recovery,
|
||
|
|
range/HLS seek, mobile background/resume, source/peer restart and storage recovery.
|
||
|
|
Verify actual transport and producer balance changes rather than relying on UI
|
||
|
|
labels. Include fresh/upgrade tests and any required IndeeHub image/catalog update
|
||
|
|
at the end of the implementation.
|