I believe NIP-94 content in Kind1 is vital to the scalability of Nostr and must become a required feature for static content URLs in the future (Image/content server hacking is a real threat to the protocol when we scale up)
So, to help achieve that vision, I will turn NIP-94 content optional for now (two buttons: regular URL or hashed/accessible URL; user's choice) if
@jb55 agrees to implement a simple NIP-94 viewer, as the spec is today, in Damus (no need to create NIP-94 events).
What do you say,
@jb55 ?
Replies (27)
never give up. never surrender.
Seems like a great compromise all around.
You donโt even need to do that. You just need to put a url hint in the tag so I can use that
I liked this ๐
โฅ ๐ค
๐ฟ
What is even more important imho is compatibility between clients. Not just standards but actually having no breaking changes and the same experience on a variety of clients
But I think NIP-94 will get adopted soon enough
But I really want Damus to implement the NIP. Please... That's the important part.
I would never break images for other clients this way. That wouldnโt be good client behaviour. I can achieve the same benefits without breaking other clients.
I am asking you to break other clients... It's a viewer for Damus users only. You don't need to write anything to break other clients.
I can see why the implementation of NIP-94 is important.
I am now copy-pasting the URL from xyz.com, which is a cute cat picture.
What if, tomorrow someone else captures rights to xyz.com tomorrow and starts serving an objectionable pic from the same URL as the earlier cute cat picture?
NIP-94 protects us from the misrepresentation of our content by people with loads of cash and power.
I am not asking you.... *sigh...
What is the advantage to your way of doing it? Iโve seen lots of arguing back and forth but nothing yet saying why you want to do it this way in the first place so badly
It's just the way the NIP was designed + the way we usually Quote any other event into a Kind 1. I am not really creating anything... I am just shipping stuff that has been already defined.
not sure how I would display it. Image urls are displayed full bleed (edge to edge ). This would break that. If anything I would implement that spec as โfile attachmentsโ as originally intended.
You can start by displaying it in the same way you display Quotes.
Sounds like images are being treated differently than other types of files, and #[2]โ wants uniformity of note architecture, and #[3]โ doesnโt wanna rebuild something thatโs already working. Idk whoโs right but canโt we make a bounty so the new viewer code is built by someone other than Will who clearly isnโt interested? Iโd donate 1M sats
You broke every other client now asking everyone else to accommodate it
Yes this seems like the core issue. Images do not look like a quoted note in damus. This would still break images even if we implemented a kind viewer for it. It would break images in all other clients as well.
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.
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.
#ClientWars #StandWithVitor
#[0]
#[1]
Never say never
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.
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.
