If you don’t want other clients to see images from your users than so be it. Once they realize that no one can see their image posts you will quickly lose users anyways. I’m done talking about this. cya ✌️
Discussion
Is there no way for Vic to implement this is a way that's backwards compatable or a way for clients to view nip-94 content without fully implementing if you don't want to?
It would have been insanely easy for him to make this backwards compatible. Instead he opted to build this on a deprecated mention spec with no url hint to make it maximally backwards *incompatible*. Bcash vibes.
The point is that NIP-94 wasn't meant to be for embedded images in kind:1 notes. If someone really wants to reference a kind:1063 they should be able to, paste a nevent code and that's fine, but they shouldn't expect other social clients to be able to understand these events, so it makes no sense to make that the default way of loading images.
The best way to ensure that the protocol is kept simple is to not assume other clients will implement whatever NIP you think it's cool -- you can implement anything you want, but you should still make it so the experience works for others that don't.
Just a Nostr pleb here but isn't that setting completely subjective standards and therefore adding politics into it?
How can we have clients competing for the best experience and most features, within the rules of the NIPs, while at the same time asking for all-vs-all compatibility?
I think a core issue is that kind1 is getting overloaded with specs. Two mention specs, quote repost. We should probably stop adding shit or kind1 posts are going to be impossible to implement in new clients.
This is why I like the longform kind, still text but we can have markdown, inline images, etc without having to overload kind1 with more interpretation and parsing.
Well said
Do nostr clients currently fetch the mime-type for each url that is inside a kind:1 note from a remote server? Or is this information embedded meaning there is no need to send a request to a remote HTTP server somewhere?
Other than privacy issues, isn't this bad for UX since there is always few seconds that images are shown as links before the UI would reflow. Is there a way to implement loading placeholder or blurhash with just kind:1 notes?
If users can't all connect on the very basics of social media like text & images, it seems to me this presents a potential hurdle of unintended censorship.
I fully agree here, #[3]. I'd stop recommending Amethyst and stop using it myself if it means that the majority of users can no longer see my images. You may be right in the long run, we don't know, but we shouldn't alienate the majority of the user base while we figure these things out.
Backwards incompatible changes to core functionality like this hurt everyone. This is how forks on open source projects can happen. If developers disagree with the direction of where an app is going, it can be forked as a new project, or a competitor will take over. The market will ultimately decide.
I find really funny that people are calling this a backward incompatible change or a "hard fork" as if it's breaking from the past.
NIP-94 is a simple new event that is now being quoted in kind 1 in the right way of doing so. This is not a breaking change at all.
This will keep happening at event kind.
This is the definition of stubborn. Clearly people are not ready for this change yet. Please show some humility. ✌
If this keeps happening Nostr won't last very long.
100%.
We need consensus of simple things like sharing photos! This is damaging for adoption of Nostr. Case in point:
My partner is new to Nostr as of a few days ago... and she's a #Damus user. My photos from Amethyst don't load on her client. I chalked it up to "new tech glitches" but the lasting impression on her is:
"Oh, so this App doesn't work" and "So photos don't work? Oh this is too confusing anyways".
😟🙁
I am sure it will... I am already working on Marketplaces events and already seeing the outcry when they are linked into Kind 1s.
Links to any other kinds are fine, the only thing that is of concern here is breaking images.
Like this 
This is a Quoted Kind1 with a link. You are displaying the image inside the Quoted Post boundaries. Just do the same for a Quoted kind 1063.
Images look like this in damus 
Not really. open this note: nostr:note16stm29mu3wpv9zu5psphv7nx54r89a028z0d9r5my3muljaml35sre4925
When you have a Quoted kind 1 the image is not edge to edge. You would do the same for kind 1063.
That note has no images in it
It’s quoting this note which has images. Your change will still break images in damus and every other client, forcing it to use quoted posts to view images. 
But NIP94 is not a direct image. It is a quote event. I would expect to be rendered as such.
Here a post with a quoted image nostr: note1z3dt56fh42r85wf7tu6hq7fcecu9xpnj8kntxeg6zpps3j9gqhxqlh
Right note id nostr:note1z3dt56fh42r85wf7tu6hq7fcecu9xpnj8kntxeg6zpps3j9gqhxqlhhmp6
Having two different ways to display images is too confusing.
A much better and backwards compatible way could be done in either two ways:
1. nevent with internal kind and image url tlv. This would at least allow other clients to use the url if they don’t want to implement the attachment nip.
2. Keep the url and reference the metadata event id in a tag with a url index.
3. Probably many other ways that wouldn’t break anything.
If you really want this to be a file attachment instead of image then you could just keep the original upload method and let users know that clients might not be able to see your image if you use a file attachment.
All up to you, but damus will not be implementing this nip for image uploads, as stated before I think it’s simpler to encode this information into a completely optional small string so that its available on the post itself and so that clients can use the information to do all the hash checking stuff, but when they are ready, not forcing it on them.
Cheers,
Agreed. It could have been done in a backwards compatible way. NIP94 is just way too short.
Maybe in future, have a Q&A section within each NIP with regards to backwards compatibility and apriori event types?
No good reason for this
Could this happen if any country censors void.cat, nostrimg.com or nostr.build ?
I agree. Please create a short tutorial on what the best practice is for building apps on top of nostr, it would greatly benefit the community. Bluesky is tackling this problem with their "Lexicon" system, perhaps nostr could do something similar?
No, if these keeps happening then Amethyst and others who engage in this kind of anti-user interest behavior won’t last very long.