Hashes to what? We are not serving immutable media that does not require optimization during runtime for the best experience. Video and audio is on a whole new level, it is not a single file if you want a good experience (HLS, DASH). All this “we must have one hash stored somewhere and never modified” is shortsighted at best, completely misses the point at worst. And don’t get me started on complete lack of foresight about delivering the media in a timely manner (milliseconds) to the clients with diverse connectivity and bandwidth constraints. Unless people start considering what is being used for what, I don’t see how we can make users (the number one priority) satisfied and enjoy their experience. And lastly, don’t get me started on all these inventions that slack any standards or even open to considering any input from the services that have real life experience working with media delivery. 🐶🐾🫡

Replies (1)

IPFS provided media delivery with Merkle DAGs. We’re bringing it to Nostr. Arranging the leaves in the order that the video plays in allows you to deliver each branch one after another, so the video progressively loads in a cryptographically verifiable way. This is what’s coming. If it isn’t signed, it can be tampered with. Don’t you see the point of Nostr is tamper-resistance? Without signatures, we’re no different than legacy media. Scaling at the cost of security is verifiability is Vitalik energy!