Why not put the URL in the content and attach a tag referencing the NIP-94 event?
Discussion
1. The `e` tag doesn't offer a URL property as per spec.
Which leads to 2
2. To figure out which URLs in `.content` must be verified by NIP-94 hash, the client will need to download all e-tags to filter the potential 1063s, then get their `url` tag. After that, the client must replace all 1063 URLs in `.content` with the appropriate `nostr:nevent` tag in the text before displaying in the screen which will then render the Quoted event as any other event as usual.
Sounds like a terrible workaround to not implement Quoted NIP-94s to me.
3. If we do that to 1063 events, do we need to do that with all other quoted events that are not kind 1?
If only we had Web SRI:
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
1. It can be a different tag, specific for NIP-94.
2. This new tag specific for NIP-94 can reference URLs that are inside .content verbatim or in other special ways, since it is custom.
3. No, if the events are not "special" and you're only interested in having most clients display their .content and .author, then you don't need special treatment. But if you want clients to do special things with them that need special code to be written, then what is the issue with adding a new special tag?
I don't have an issue with adding a custom tag. I just don't understand why to add bloat when there is no need to.
But if everyone is ok with.. then.. bloat it is.
I certainly prefer to keep kind 1 clean with simple NIP 27 uris for every tipe of event. But looks like no one cares about that these days.
NIP 95 won't offer an option for a tag (there is no URL) so... I really don't think custom tags are a good design pattern. People will have to deal with other events sooner or later.
👀
I'm surprised that Web SRI is not part of nostr.
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
I like this solution because it allows apps to make use of NIP-94 events for files that the user doesn’t necessarily want or need to be displayed directly in their social feed.
Most clients haven't even fully implemented NIP-65/Gossip and a coinciding relay picker autopilot, which means any huge surge of new users on one of them would cluster/centralize onto a few relays and crush them....and yet we're spending all this premature optimization time on a file metadata NIP? lol