because i wanted to load the blur hash immediately after receiving a note.
Discussion
Oh yeah that seems like a huge flaw in 94. Maybe we should edit NIP-94 and let people just put all those tags like `blurhash` on kind 1 or any other event.
Also we really need an ID for finding media when all these files are no longer at their original locations. I don’t care if it’s sha256, torrent info hash, or something else.
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.
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).