I actually read that one first. I think it sounds cool and if it integrates more tightly with Nostr then that’s great. I’m just not understanding how this fixes issues Will pressed so hard on of having a centralized repository and exposing user IP addresses, since all the gifs are being imported and hosted on Nostr.build which is still centralized. If those truly are major issues (are they?), then how does this address that?
Discussion
I think Nostr clients will build search using nip-94, so the gifs don’t need to be stored on nostr.build. nostr:npub1hee433872q2gen90cqh2ypwcq9z7y5ugn23etrd2l2rrwpruss8qwmrsv6 is just backing them up there while also creating nip-94 events.
Clients could build a gif search using tenor or giphy API by using a proxy which I think solves the privacy issue, but with nip-94 we’re not reliant on these APIs where the service can ban or rate limit you at any time.
What’s the gist of nip-94? Resilient access to media is good, if I’m understanding you correctly. May be less important/crucial for fun GIFs that we share in passing, but more important in other cases depending on the contents of the media.
Nip-94 is storing metadata about files anywhere on the internet https://github.com/nostr-protocol/nips/blob/master/94.md
I was more trying to get at that the gif search won’t just stop working out of nowhere for Nostr clients.
And now that I think about it, Nostr clients might need users to get their own API keys for Giphy and Tenor APIs. The privacy problem is not solved with a proxy in that case. The business model for those companies is to sell user data to as many companies as possible.