Like this? The NIP doesn't spec how tags for search should be included. Do you expect this to be under "alt (optional) description for accessibility" or should the NIP be updated to permit such search terms?
['EVENT', {'id': 'dac293072f3c67d2e0448dfaf6e0403c93681e643944c616ef25827246141234',
'pubkey': '7c3be2769c76eecd6c6e27276722dfae0d8ad201825253452153b90093c41654',
'created_at': 1719985905,
'kind': 1063,
'tags': [
['url', 'https://media.tenor.com/6TcA9vRym4MAAAAC/laugh-mock.gif'],
['m', 'image/gif'],
['x', '5a492e2cc6408086593e4a6bca6f3af604297918e200ed828b842818710a5548'],
['ox', '5a492e2cc6408086593e4a6bca6f3af604297918e200ed828b842818710a5548'],
['size', '28257'],
['dim', '203x200'],
['thumb', 'https://media.tenor.com/6TcA9vRym4MAAAAT/laugh-mock.png'],
['image', 'https://media.tenor.com/6TcA9vRym4MAAAAe/laugh-mock.png']],
'content': 'liotta mock laugh',
'sig': '538058211c516ef7edb07fdb4fcfb65e8883c7a225f336993124911f49bcdaf0eeb70a4b281cfd7cc1d0963b98cdb1d768ef7fa07b905cb3d8c662904a658d42'}]
I like the idea of classifying file metadata so that it can be parsed in a search, but the NIP itself doesn't solve the original repository problem, right? By this I mean, where do we find the gifs to feed event kinds 1063? That's where I feel like an a supplementary service is needed to start (e.g. Tenor, Giphy, etc). Let me know if I'm thinking about this in the wrong way.
With client support, any user can contribute to the repository, so a group of friends could build their own. You can also use third party repositories
If I build a script that takes common meme searches (like “lol”, “angry”, “wtf”, etc) and associates the search term with a Tenor gif result and then posts it as a Kind 1063, would that help to get this going?
I took your advice and built a gif nostr companion app:
https://gifbuddy.lol/
You can download the PWA to your home screen, search for your gif, copy the address and paste it into your client
On the back end, for every gif that gets copied/clicked, an API request is made to upload to @nostr.build by @The Fishcake🐶🐾
From there a nip94 request is done so that the content can be accessed by any client in the future
Now, anyone who searches for gifs using this tool is also helping to build the gif repository for nip94 and adding fallback urls to nostr.build
And all they did was click to copy #gifs
https://media.tenor.com/VrufNvHPA1QAAAAC/i-hope-you-guys-are-proud-of-me-chris-c.gif
nostr:nprofile1qqstuu6ccnl9q9yvejhuqt4zqhvqz30z2wyf4gu43k404p3hq37ggrspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsq32amnwvaz7tm9v3jkutnwdaehgu3wd3skueq4kymtq you've got me scrolling rapidly specifically looking for notes I want to respond to via gif
Nice and useful work!
I would suggest reflecting the research as permalinks, to make it easily shareable.
Nice work!
It's hustle like this that I think is so interesting when it comes to the power of open protocol's
It's in everyone's interest to improve things... VERY powerful network effect long term
Now I need to work out how to do what you're saying!
Amazing work - well done and thank you 🫂
If I can’t find a specific gif, is there a way for me to add it?
Looks like it's grabbing from tenor. You can create an account there and upload
That makes a lot of sense. I think I have some from giphy too. Thanks man!
Nice! https://media.tenor.com/uLaUQ1PR-FIAAAAC/anonymous-anonymous-bites-back.gif
it's not copying the new URL. Only taking the tenor one. It says it is copied but isn't maybe you need a prompt for brave to ask permissions to use the clipboard? Brave on Linux Mint. If it showed the full url in the pop up it could also manually be copied.
The copied link is a Tenor link by intent
When you click a gif, a separate API call is made on the back end to upload to nostr.build
That process takes time that would really hinder the user experience if you had to wait for the new url to be generated in order copy it; it’s several seconds
I could potentially make a separate API that will return URL instantly, and will redirect to Tenor while upload is prepared, and then serve local copy. If you are interested, let me know.
There have been a couple comments in my feed from people expecting to paste a nostr.build address so that could be cool
Your API is fast already, it's mostly that nip98 AUTH requires me to publish a Kind 27235 note, which takes time to broadcast with my current library
Were you thinking this API would be separate from nip98?
Nip98 does not require anything, just a signed header. You are talking about nip94, that can be pushed async.
I would probably need that for user uploaded gifs actually now that I think about it more
Hello is this the comment section that sucks your data plans balls dry?
@fiatjaf one for https://nostrapps.com
You have been chosen to send a patch for it.
Let me know when you have done it.
I couldn’t find it on GitHub and couldn’t see a way to submit a new app on the site.
Building static paths to serve files (gifs on this case) is not a good path for decentralization. It would be better to store the sha256 of the file on the note and then query the relays if they have that hash on their disks.
This way you don't care which server the file is coming from, it might even be cached on the machine and notes will be future-proof like the rest of nostr.
That’s what nip94 allows for and that’s what gets published once it’s uploaded to @nostr.build
If you read the specification, a nip94 event has the sha256 hash, a url and a fallback url
The url is convenient right now because no clients that I’m aware of query sha256 hashes like you are mentioning; however, this process sets up that foundation to be possible in the future for clients to query hashes like you’re proposing
Thank you for the note, hadn't read that NIP yet. Happy these issues got addressed beforehand. Plus points for the torrent field inside.
I will pack everything inside a zip archive and then use NIP94 for sharing it.