nip94 gives us the ability to build giphy on nostr itself. Anyone can publish a nip94 note of a gif, and clients can optionally publish these notes when you share a gif, so you can find gifs your friends use. gif services can also publish these notes.

nip94 is file metadata. It’s a perfect usecase for this.

The contents of file metadata is a description of the gif, search engines can use this to do gif searches.

You can also add tags to the metadata note, so you can search on the image/gif mime type and the “lol” tag to quickly find lol gifs.

We have everything we need to start building this.

Reply to this note

Please Login to reply.

Discussion

Don't understand this desperate need for gif keyboards

i did not either … but its a very common request 🤷‍♂️

Because it is temporary solution that can save time switching off between apps. Once you guys you stated above just replace.

*once you built stated above

It’s so that people don’t spam the same meme image 100k times. Huge waste of space. Just reference the one image 100k times.

I would never quote the file metadata note directly though, its mainly for searching gifs and putting the url from that into a post. Still would save lots of space on nostr.build, and people wouldn’t have to reupload gifs all the time.

these are very good points

It's not really "gif keyboard" they're after; it's in-app gifs. Shouldn't need to leave the app just to enhance the expressiveness of your note through memes

Finally! 🔥🤩💜🫂

#nip94

Am I doing this tagging correctly? 😆

I just finished launching out “Make a meme” feature on Memestr and i was thinking I can extend this with make a gif feature from the videos. This is gonna be super useful.

Thank you for this update. 👏🏻

relay.nostr.band already supports nip-50 searching across file metadata events, so yes it's all there https://nostr.band/?q=gif+kind%3A1063

very nice. the relay seems a bit unstable though :(

what issues are you seeing? it has aggressive rate limits, but should be fine aside from that

This could also be a huge win for #accessibility on Nostr. Media accessibility is in a pretty sorry state. Nostr doesn’t even have alt tags.

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', ''],

['m', 'image/gif'],

['x', '5a492e2cc6408086593e4a6bca6f3af604297918e200ed828b842818710a5548'],

['ox', '5a492e2cc6408086593e4a6bca6f3af604297918e200ed828b842818710a5548'],

['size', '28257'],

['dim', '203x200'],

['thumb', ''],

['image', '']],

'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:npub1nxy4qpqnld6kmpphjykvx2lqwvxmuxluddwjamm4nc29ds3elyzsm5avr7 by nostr:npub137c5pd8gmhhe0njtsgwjgunc5xjr2vmzvglkgqs5sjeh972gqqxqjak37w

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

I never thought that seeing Bandido doing some headscissors on nostr.

👀

🫡🫡🫡

Great!

Too many gifs in my feed! 😂😂😂

Testing

Hmm now i have a link to tenor?

It gives tenor link and does upload async after that.

So it comes into effect if tenor decides to take down the media or dies, as a backup source. Nice.

Nice code

Smooth!

I test

Neat!

could it finally be true

so good I accidentally did it twice

Nice and useful work!

I would suggest reflecting the research as permalinks, to make it easily shareable.

The copy gif url on touch feature is nice!

And it also uploads it to nostr.build in the background.

let's test this going waaaay back...

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!

It works!

This is incredible and you accidentally made my new favourite gif search in the process. Ty

Me entering the arena after nostr:npub1hee433872q2gen90cqh2ypwcq9z7y5ugn23etrd2l2rrwpruss8qwmrsv6 gave this new gif super power.

Lfg!

🔥 so nice

Droideka cat 😳

LFG

Testing

Amazing work - well done and thank you 🫂

Wow! It's so fast too! Any way to keep scrolling down to see more gifs?

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!

This app is cooking!

I did have to save it to my phone first I didn't see an option like that but it worked heck yeah

Very proud!!!!

Nice!

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

Well done

Hello is this the comment section that sucks your data plans balls dry?

Awesome, thanks!

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:npub1nxy4qpqnld6kmpphjykvx2lqwvxmuxluddwjamm4nc29ds3elyzsm5avr7

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.