We really should standardize on a solution for this. I actually was just working on something similar, an embeddable `nfile` entity. This fails the naive fallback test, but I don't like that nip 54 prioritizes one url in particular. This way we don't need a full event too, just a data structure that can add blurhash etc as needed.

nostr:nevent1qqswc3dr5zwqh6dn9m5pgruy90y40atd9dl4q8ajy8rckmhun7g9u5spz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9rhwden5te0wfjkcctev93xcefwdaexwtcpzdmhxue69uhk7enxvd5xz6tw9ec82c30qyvhwumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdshsz8rhwden5te0vf6kx6m9wshxxmmjv93kcefwwdhkx6tpdshszrnhwden5te0dehhxtnvdakz7qgnwaehxw309ac82unsd3jhqct89ejhxtcpr3mhxue69uhkx6rjd9ehgurfd3kzumn0wd68yvfwvdhk6tcpzemhxue69uhhyetvv9ujumt0wd68ytnsw43z7qgjwaehxw309ac82unsd3jhqct89ejhxwvcy34

Reply to this note

Please Login to reply.

Discussion

What do you mean prioritizes one url? Isn’t the data stored in the fragment so you can add metadata to any url in the content ?

NIP 54 does example1.com#blurhash=whatever. I assume you could do `alt` hash values for alternative urls, but nothing in the PR mentions that. I basically want content-addressing for images like we have for events, rather than the hacky hash fragment approach. NIP 94 gets you this, but it's a pretty bulky payload to pass around if you want to avoid dereferencing an event id (and possibly failing).