I feel like this could work fine on Damus with a little tinkering. When Damus initially received and renders an event that mentions a file attachment it can show it as a note mention, and once it pulls in the note and sees that it’s an image file it can upgrade the display of the note from inline note mention to an inline image. If the transition can be done smoothly without screwing up your scroll position it would be nice.

It’s definitely more complicated than regular inline image URLs, because now to render you need to have both the text note and the file attachment note, but it’s not impossible.

Reply to this note

Please Login to reply.

Discussion

Damus can of course do it but it’s making nostr worse by forcing this update on everyone and making it harder to show images. Damus will never implement creating image uploads this way for this reason.

Perhaps this is all due to a lack of power on the relay side. You kind of want to ask relays to send mentioned file attachment event alongside the main event in the same subscription, so you don’t have to fetch things separately that you’ll always want to process together.

But perhaps that’s straying too far from the simplicity of the protocol…

#[2]​ idk I think you’ve hit a wall. Push for everything else but images to be implemented this way and maybe someday images will join the pack when lower hanging fruit has already been picked, too many things to build right now to rebuild old things yet.

Ehm Ehm Nip57 - LNaddress servers.

Never say never

Harder right now, perhaps, and I agree that for the time being let’s not break images and keep them inline.

But in the long term, if we discourage referencing other notes from within kind 1s we will end up continually adding more functionality inside kind 1s instead of giving each function a separate kind. The latter is more modular and cleaner to implement, the sole pain point being that you need to pull in referenced notes in order to render the text note properly, which just isn’t reliable right now.

Agreed that images are so common in kind:1 notes that it would be wise to require a sub resource integrity digest within kind:1 notes itself.

Users should be able to opt-out of this behavior: Any images without an SRI hash will not be shown inline, but will be shown as a link.

Images with SRI hash: safe to display inline.

Images with no SRI hash: Not safe. Only a matter of time that all your previous kind:1 notes will show porn or propaganda since those can be hacked.