Thread

Streaming video, paid via Cashu micropayments Like Lightning, many payments can be made per second. Tiny payments - e.g. 1sat per kilobyte - can be made and verified just between the video player and video server, only contacting the Cashu mint when closing the channel The client-side logic could be put into a browser extension or any Nostr client, allowing the user a single system to manage (micro-)payment channels to Nostr relays and Blossom media servers and (@TollGate ) Wifi routers I'll post a lot more about all this in coming weeks The Rust code is exposed via WASM to the browser-based video player, and also to the Python server via PyO3, which should help the server to verify very high volumes of payments This video system uses HLS, which is smart about bandwidth management and I think it's compatible with Blossom, so I hope that makes it easy to integrate this system - with payments of course - into Blossom Current draft protocol, very much subject to change:
GitHub
NUT-XX: Offline Spilman (unidirectional) channel by SatsAndSports · Pull Request #296 · cashubtc/nuts
Update: 2025-11-17: big rewrite. Less discussion, more details, deterministic outputs With this NUT, Alice and Bob can - using any mint supporting ...

Replies (3)

↩ replying to Arjen
Short answer: yes The client, i.e. the video player, can handle multiple channels with the channel data and state stored in the browser's storage ("IndexedDb") And the server doesn't care which channel is used to pay for a particular segment of video. Each segment is just a few seconds of video, hosted on Blossom, and the blossom server doesn't care about users or videos. The only 'state' maintained by the server is the current balance of each channel, in order that the channel can detect if somebody tries to "rewind" a channel to a previous state So rollover will be a client feature (not implemented yet, but soon), and the protocol and server don't need to know about any rollovers