NIP-94: Add optional 'download' flag

[michaelhall923]

In Stemstr, we have notes that present the same audio file as both a downloadable wav file and a streamable m3u8. We would like other clients to know that the wav is meant to be downloaded and the m3u8 is meant to be played inline.

The proposed change is adding a "download" flag to NIP-94 to signal this intent.

[arthurfranca]

I think it is a good addition and is similar to HTTP Content-Disposition header that is either "inline" or "attachment", so download tag "0" or "1".

[michaelhall923]

Didn't know about that header. This might be redundant if we can just set a Content-Disposition header. I guess the question is are clients likely to honor that header?

[arthurfranca]

Browsers honor it but custom clients may not. And a NIP-94 event received by websocket won't have a header.

If you were thinking of using urls directly instead of NIP-94, you could use NIP-54 - Inline Resource Metadata that accepts all NIP-94 tags and make an url like https://xyz.com/example.wav#download=1 which clients would know it is to be downloaded without needing to request the file to learn the header.

So it's good to add it to NIP-94 so to make it available to NIP-54.

[vitorpamplona]

I would invert this. I'd keep the wav in the url tag, to avoid having to modify how to hash/verify the file, and use the tag ["streaming", "<url>"] for the less common m3u8 file which cannot be verified with the hash. Clients supporting streaming protocols can use streaming and keep url as a fallback.

[Semisol]

what about the tag being present instead?

[michaelhall923]

that makes sense