nostr:nevent1qqsxjpg89whknpwv86s9d9u0q3vgn7eq6afca7ds5jgqe4mhyrr7asgpzemhxue69uhhyetvv9ujumt0wd68ytnsw43z7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uqsuamnwvaz7tmwdaejumr0dshsqu5yud

What a piece of hell is this?

NIP-94 was never intended to be used for inline images in social clients, right? It was meant for those other apps that would create markes for files and other crazy filesharing applications.

nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49

Please don't do this. Please don't break backwards-compatibility in these crazy ways.

Reply to this note

Please Login to reply.

Discussion

A link is a link right? I only implemented parsing NIP-94 links for now

Exactly. I didn’t not expect it to be used this way either. If we want image metadata we can include it in a small TLV encoded string in the tags that references the URL (by index)

💯💯💯

For real wtf 😁

?cid=2154d3d7m0kfrerb3q7f8kp19mbmh69twlwgzyxul1662ja2&rid=giphy.gif&ct=g

I agree. For the sake of simplicity interoperability it doesn't make sense to have multiple competing ways of embedding media in a basic social feed. That's just going to make it harder for client developers.

The definition of a hypertext reference or resource could be revisited.

Afterall, it's strange that Subresource Integrity is not part of nostr notes, considering that in the world of NFTs, JSON referring to external images are hashed.

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity