Thread

nhash is a blossom hash of a video file's merkle root + decryption key. /video.mp4 is a filename hint. It's viewable on Iris or

Nice! I'm going to have to steal that idea for CashuTube 😀, the site that serves HLS-encoded via (adaptive bandwidth) and which requires cashu payments Of course, the server doesn't need to know the decryption key. And so web players could have the decryption key in the # portion of address.

CashuTube

Decentralized video streaming powered by Cashu ecash and Blossom storage. Pay-per-segment, no accounts, no tracking.

Here's the ts & rust library

Iris Files

"Merkle roots can be published to get mutable npub/tree/path addresses" Cool! So a query to that will return a signature of the hash by that npub, perhaps in a header in the response?

Yes, it uses kind 30078 events with tags: d Tree name (replaceable event key) l "hashtree" label for discovery hash Merkle root SHA256 (64 hex chars) key Decryption key (public trees) encryptedKey XOR'd key (link-visible trees) selfEncryptedKey NIP-44 encrypted (private/link-visible)

And the merkle root is of a tree of equally-size blobs? I ask because that might make it easy to skip to the relevant part of the video. Do we know the depth of the tree? Although, I guess you have this size (and runtime?) metadata somewhere in the nodes of the tree?

Usually equally sized leaf nodes, but that's not enforced. Actually I made a video-chunker which makes the first chunk 256kb so it starts faster, while the rest are 2MB. Bittorrent v2 compatible 16kb would have been nice, but it's too much overhead for blossom servers.

On

Iris Video

(source code in the hashtree repo iris-files package) I have a service worker that handles http range requests to /htree/nhash... and the browser video player can request only the relevant part of the file from the hashtree.