archy/docs/indeehub-fips-protocol-review.md

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: 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: describes file hashes, MIME types, sizes and locations. Reuse compatible fields rather than inventing incompatible meanings for standard tags.
• Blossom BUD-01: 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: 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 and NUT-23: 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.