Nostr Web Client

The mind blowing part here is not my unix tool, it is showing that nostr is a practical decentralized alternative to Usenet NZBs (torrents are a different thing)

- Blossom servers do not need to store a whole large video file

- Blossom servers do not need to stream an entire large file

- Blossom operators have plausible deniability in terms of content as the segments are encrypted (and they may not have all) and they don't control the key

- Video clients now have mutiple failovers if a segment is stored in multiple servers

- There are bandwidth savings if the video is not watched entirely

- Content creators can exchange the AES key against a zap

Youtube, here we come.

nostr:nevent1qqs95v5s99w5mzegk6tdf5flu0af999k0anjkucdcemf2d5hh9hk43qprpmhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0qgs8y6s7ycwvv36xwn5zsh3e2xemkyumaxnh85dv7jwus6xmscdpcygrqsqqqqqpr4rtmd

florian 8mo ago

I’ve been experimenting with HLS on blossom but I had put the m3u8 in blossom as well.

Generating the m3u8 playlist dynamically makes more sense and enables nice features like the aes encryption.

I was solving the server failover on the fly in the browser while playing but doing it before playing with HEAD requests is also reasonable (short delay).

We could have a kind 21 video event pointing to multiple 1663 events and generate a master playlist dynamically to support multiple resolutions.

I will build a browser version of your demo if no one else beats me to it.

Reply to this note

Please Login to reply.

Discussion

franzap 8mo ago

Failover on the fly sounds even better!

Mine was a shitty proof of concept, you are much more familiar with all this so happy to keep chatting about a potential NIP that makes sense.