For building nostr native gif keyboards maybe we need to start with gif collections or gif lists before we starting building a gif search tool

Maybe we could add a k:10915 and k:30915 to NIP-51 that would work similar to the NIP-30 emoji sets with ["gif", "name", "", "] tags

Then tools like https://gifbuddy.lol/ could have a "add to collection" buttons on gifs and then social apps could pull the collections down and allow users to pick from them

Then stage two could be searching the gif collection of your friends and WoT...

CC nostr:npub1hee433872q2gen90cqh2ypwcq9z7y5ugn23etrd2l2rrwpruss8qwmrsv6 nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft

Reply to this note

Please Login to reply.

Discussion

YES!! Now we're thinking. I'd like to have this with custom emoji packs too... Perhaps it already is this way, but I still don't know how to explore them on amethyst or nostrudle, or anything for that matter.

This app is great for creating packs https://emojito.meme/ and if you favorite them on there they will show up in noStrudel

Oh hell yeah!! Thank you!

I currently use nip94 to do this and there is an upload tab on Gifbuddy for users to add their own gif (which should show up almost immediately on nostr search)

The counter on the main page is logging the size of the nip94 repository for GIFs published by Gifbuddy

My first reaction is that adding a new kind would reset the progress and split the dataset, but I may be missing something

Why nip51 over nip94?

I actually already have a nostr native gif search engine that queries nip94 events, but haven’t advertised it much because the index is too small (<6,000):

https://gifbuddy.lol/nostr

I'd say we use both. NIP-94 is great for keeping track of the gifs and publishing them to nostr, but I think it would be cool for users to customize their own gif collection so they didn't have to search for gifs every time

I think I see where you’re coming from now

nip94 will be the entire dataset

nip51 will be user favorites for quick clicks

So users would sign an event and their favorite or most used GIFs would be tied to their public key that clients could use for better UX

Is that right?

yeah, NIP-51 has bookmark events that could be used for flavoring specific gifs or sets. and "sets" which could be user made collections of gifs

Looks like people are already doing this with emojito by nostr:nprofile1qythwumn8ghj7enfd36x2u3wdehhxarj9emkjmn9qyt8wumn8ghj7enjv4h8xtnwdaehgu339e3k7mgpp4mhxue69uhkummn9ekx7mqqypl62m6ad932k83u6sjwwkxrqq4cve0hkrvdem5la83g34m4rtqege7llfh and it's just being published under kind 30030

Do we even need a new kind? 🤷‍♂️

Seems like nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq3qamnwvaz7tmwdaehgu3wd4hk6tcpz9mhxue69uhkummnw3ezuamfdejj7qghwaehxw309amxjar0wghxummnw3erztnrdakj7qpqgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqyw43nv is just working around it client-side

nostr:nprofile1qyv8wue69uhk6mmwv9jzu6nzx56jucm0d5arsvpcxqq3wamnwvaz7tm9vdkxjurnv5h8qatz9aex2mrp0yqs6amnwvaz7tmwdaejumr0dsq3qamnwvaz7tmwdaehgu3wwa5kuegpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq32amnwvaz7tmjv4kxz7fwd4hhxarj9ec82cspzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqpqxtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzs6dze5x , this seems to be a pretty good idea; I think it's still best paired with a global search library so you aren't bound by the collection you have, but it's nostr native and api-limit free

Example event:

{

"created_at": 1717552866,

"content": "",

"tags": [

[

"d",

"Reacts"

],

[

"title",

"Reacts"

],

[

"emoji",

"puppyeyes",

""

],

...

,

[

"emoji",

"whatthefuck",

""

]

],

"kind": 30030,

"pubkey": "d7607464225c8ab610da99495bc70c8a3a45a03f8a22a95f06fcb5bc421e573a",

"id": "518b723ae57751bfadd37a6744159f41fda5d95638b89a3e9e728762e9531188",

"sig": "791db349d5fc87b4a9daef13c9181783b0c5e5f735ce446386d6e7e573000817a0d031e70edd2238b2da0b302ed622149ca533d04f3c4aaaa0390817b4909733"

}

Reference library:

https://emojito.meme/a/naddr1qqr9yetpvd68xqgkwaehxw309an8yetwwvhxummnw3erztnrdaksygxhvp6xggju32mppk5ef9duwry28fz6q0u2y2547phukk7yy8jh8gpsgqqqw48q447449

This is define on nip 30 and nip 51

Please don't mix gifs and emoji kinds. Its just going to create more work for clients to filter out each type

When I doubt it *always* better to use a new kind

I think it's already happening on emojito currently

But I'll use k:10915 and k:30915 for what I'm about to do next

How did you come up with those numbers?

As opposed to 10031 and 30031 or any other arbitrary number in 10XXX and 30XXX. I've never understood how kind numbers are assigned.

Adding nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z

If everyone is cool with Kind 10915 and Kind 30915, I’ll start building with that for nip51 gif collections

The number is random, just pressed a few keys on my keyboard

We could use another simpler number if we wanted

Either way we should write up a simple spec for gif sets that is similar to NIP-30

We need to define what type of tags these events will have and how they should be used

the ranges are defined, 10k is replaceable, 20k is ephemeral, 30k is parameterized replaceable - there are a few exceptions to that based on numbers that were defined before that range scheme was defined (such as kind 0 being replaceable) - other than that, people just pluck numbers out of teh air and they stick if they get used and baked into the nips repo

Awesome, can't wait to add gif collections to Chachi! I'll use those kinds.

Lgtm

Emojis are designed to be small and embedded in text, gifs are full sized image reactions. Clients are going to use them for different things

yes good idea