Replies (77)
maybe you are wrong, time will tell
This is so misleading. Just because the nip was merged doesn’t mean it was meant to replace inline images
View quoted note →This is the same way we quote everything else. Polls, Long form content, other Kind 1s... It's still in spec.
Kind 1s don't require inline images.
Debate is good and constructive in working out the details. The lines aren’t as clear as black and white. Come into The Bitcoin Lobby and discuss. Conversations are better than text 🤙 😃
Nostr Nests
Join this audio Space
I tend to agree it's not cool for the biggest client to just invent new standards without asking, but if he manages to make something that works and is backwards-compatible that could be good.
But I think the biggest issue here is that you've implemented NIP-94 on Amethyst in a way no one (I think) expected it to be implemented: for inline images -- which is probably a fault of the NIP and the discussions not ever being clear about their intents and purposes. We should address that by rewording the NIP.
Debating this is good and healthy for the protocol. We should come to consensus about how this NIP should be implemented though. Users want their content to be seen and and they'll use whichever client or clients allow that to happen.
Heheheheh "consensus" heheheheh
Any Nostr event can be quoted in a Kind 1 with nostr:nevent... That means any new event kind can be quoted.
Damus doesn't need to load the preview if they thing the preview is slow. They can simple do an @note1 text and get users to click on it.
This cannot be happening 🤦♂️
Nest frog talk right now about it
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 ✌️
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.
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.
Weak moves. Ego…
If that's the case the only solution may be to put dasmus on Android and let the users decide.
I stand with #[1] 🫡
Who stands with me?
#[0]
So no to hard forks
#[0]
damus on android isn't a bad idea though
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.
Why would you become tribal about something like this
If(response.type == nip-94){
//do nips
}
else{
//no nips :(
}
I just want to be clear where we stand
I could not zap this note. 💜
I am favor of there being a standardized way of sharing files within notes, but nip-94 seems to be something completely different than that
Thanks for sharing where you stand 🫡
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.
Nevermind.
Collaboration and consensus building can always be achieved. Everyone just needs to talk it through with cool heads.
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.
Sheesh. Happy Monday
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?
The world will reach Consensus whether they like it or not. ….
Why tho
Why not?
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
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".
😟🙁
Yes. Clients don't have to be the same...
But not even loading photos is a HUGE issue.
#[3] let’s try really hard to not make the same mistake done here kind sir 🙏
How is proposing an optional header to a NIP comparable to this in any way? Our relays will never implement non-backwards compatible changes in this way - full stop. If clients can’t access our relays we lose all of our value. I think you completely misunderstand where I’m coming from.
I am sure it will... I am already working on Marketplaces events and already seeing the outcry when they are linked into Kind 1s.
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.
Links to any other kinds are fine, the only thing that is of concern here is breaking images.
I didn’t say any of that... I half expected you to reply with something along the lines: we won’t let it happen under our watch ✊
Oh well it’s Monday and I didn’t intent to join the drama so I apologize and please forget I tagged you
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.
No good reason for this
Images look like this in damus
Not really. open this note:
View quoted note →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.
😂 very well, my apologies then. The timing was odd given the conversation we just had about NIP98 and the context of this thread.
I am passionate about making sure people get their notes and other stuff. We won’t let it happen. 🫂
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
Nostr is evolving but also testing its consensus limits
#[0]
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,
😆
#[3]
🫂
Could this happen if any country censors void.cat, nostrimg.com or nostr.build ?
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?
Valid argument here. Links are links. Just like an <a href> tag in HTML is not an <img> tag.
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?
wen New York Agreement? 😂
I was off for a while. what is the current block size?
The second implementation matters since it makes the NIP official?
#[3]
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.
