Shouldn't take very long. Implementing NIP 94 to view urls is extremely easy. Posting is a bit harder.
Discussion
Should have made them backwards compatible imo. Didn’t need to hardfork like this. Could have just referenced urls in tags.
These seems like strongarming other clients to implement some spec they may not want to implement. Now we have broken images from a major nostr client. Are you implementing images this way #[5] ?
The idea is to not stop at images. PDFs, music, APKs, etc. Everything will be hashed.
420 buy signal folks.
Agree, we need backwards compatibility until consensus is reached. Breaking functionality to force a change is not cool.
Normally it’s fine but this completely breaks a core feature in most clients (images). Doing this in a backwards incompatible way is just way too much. Good to hear he’s switching back to urls.
I want to use the magnet links so probably, damus can continue to use the url. But it's not optimal
I already implemented nip94 on snort but only for parsing other clients didn't implement it yet som I'm just waiting
I think magnet links should be built on https://webtorrent.io instead of a non-browser-accessible protocol.
Changing to urls soon. I just haven't switched to the non #[] tagging yet. But seriously, it's not that hard. And it's the right way of doing this.
Really ? I now have to fetch x extra notes for every post that has x images? Damus will not implement it this way, I will include this info in the tags if need be.
Then your users will be missing out. I don't understand the resistance. It doesn't add anything to the processing time.
Damus is fast because it can render notes the second the kind 1 is returned. Now I have to wait even longer? No thanks.
Damus users are not missing out, you are simply isolating your users from the rest of nostr.
I don't get why it would be slower. In Amethyst, there is virtually no visible difference in download and rendering time between the two. iPhones should be able to handle this even better.
Btw, the same spec gives clients accessibility information for the blind. I think not implementing it is isolating Damus to priviledged users.
How would adding another query round trip not add extra latency? What? It would add at least another 100ms on average. Saying there’s virtually no difference in rendering time isn’t the point.
Not to mention it would cause extra popping-in unless you are waiting until you get all the attachments before putting it in the timeline…
Sorry to drop in. Can someone explain what’s happening? I’m working on an image-based feature and I’d like to understand what changes (if any) I should be anticipating. 😅
Take a look in NIP-94. It adds a hash to verify ifnthe picture has be doctored by the server, a blurhash to show when loading and a description for accessibility. It's a great spec.
Thanks! Just read it.
It seems like the argument against is that it creates an extra step (client has to query the 1063 event then fetch the image).
The nip doesn’t seem to specify how to reference the image from a kind=1 note. I guess it’s expected to be the #[] content + ‘e’ tag nomenclature?
Side note: the nip doesn’t specify which tags are required/optional and whether any can be repeated. For example, could multiple ‘url’ tags be provided for failover?
Are 1063 events replaceable? For example, if the canonical url of an image were to change for some reason.
Is there a list of allowed protocols for the url? One might assume http:// and https://. What about data:// URI’s?
> The nip doesn’t seem to specify how to reference the image from a kind=1 note.
Yep, we just do what we usually do for every other referenced post, either the old #[] or the new nostr:nevent.
> Side note: the nip doesn’t specify which tags are required/optional and whether any can be repeated.
Yep. We should probably refine the text as we figure out the details.
> Are 1063 events replaceable?
They are not replaceable.
> Is there a list of allowed protocols for the URL?
Amethyst assumes any URI. As a viewer, we must support whatever comes in.
#[4] is replacing urls with notes that you have to fetch to get the url which adds extra latency to image loading. I would rather just have this info in the kind1 tags so I don’t have to n+x notes for every note in the timeline.
The extra metadata is great and I will likely do something similar, but I probably won’t have it in a separate note.
Makes sense, thanks for explaining! 🙏
Guys, I was watching the entire conversation with 🍿
was here by accident , do not regret it
😂 coding reality show
Absolutely. I find it funny that the thread starts we me posting « I’m tired… » then they barged in.
«Jb comes from the right to aggressively tackle the issue »
« Vitor Pamplona attempts to deflect the attack. It looks as if maybe… »
« But Jb doesn’t give up and tries again from the left »
« Vitor Pamplona seems to have found a way to maybe divert the flow of the action in the other direction »
« no, What a shocker pablof7z enters the ring unexpectedly tapped in by jb55 
😂😂😂😂
LOL
That sums it up! 😂
Oh and by the way, I had to go back to an older version of Amethyst because I want to be able to upload images that everyone can see directly in my client.
So tell me if you can see the image that started it all! 😉
how to add two image with NIP-94?
I’m not entirely sure. My guess would be that in the kind=1 note content, you’d have # [0] and # [1]. Then in the tags, you’d have two ‘e’ tags pointing to two different kind=1063 (NIP-94) events.
I still support kind 1 event with urls in content.
and NIP-94 event will also showed but don't be send from my client.
this situation is exactly what major clients need to take into account, each breaking change imposes a tax on everyone else that is running a small client
nostr: metions are superior to #[], but now I am forced to go back and update a bunch of clients I wrote just to regain what was previously working
it's ok for new features, but breaking functionality must be embraced very slowly
Developing nostr so fast with so many different clients gaining traction, I'm surprised things like this haven't been more common. Challenging forks are bound to happen, nostr has no consensus mechanism whatsoever.