Integrating GIF buddy into clients has been tricky because every developer is different

I made a GIF Buddy API for Corny Chat by nostr:npub1yx6pjypd4r7qh2gysjhvjd9l2km6hnm4amdnjyjw3467fy05rf0qfp7kza

I built a tool for creating personalized GIF Collections that uses a custom NIP used in ChaChi by nostr:npub107jk7htfv243u0x5ynn43scq9wrxtaasmrwwa8lfu2ydwag6cx2quqncxg

I publish every GIF that’s copied as a public event under NIP94 that other clients can freely access like noStrudel by nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr

I deployed my own relay where all the GIF related events are publically accessible under:

wss://relay.gifbuddy.lol

And I’m personally trying to code GIFs into nostr:npub18m76awca3y37hkvuneavuw6pjj4525fw90necxmadrvjg0sdy6qsngq955

My goal is to have GIFs (and even memes) in every client, but trying to build a single thing that satisfies each developer has been a challenge so much of my work has been split and pulled into different directions

Part of the challenge is that Nostr clients are inherently all built so differently: web vs. native, iOS vs. Android, one programming language vs. another

Slowly but surely we will get there

GIFs are inevitable

Reply to this note

Please Login to reply.

Discussion

Nothing stops this meme train

I'm considering building a Javascript SDK for GIF Buddy

I'm just brainstorming the idea now and am not entirely sure if it's the best approach, but I think the Software Development Kit would need to include:

- NIP94 media search (memes, GIFs, mp4 uploads)

- Semantic search ordered by relevance

- Search by relay

- GIF & meme collections by npub

- Event publishing to edit collections and build media repositories

- No API limits or API keys/Nostr-native

This could be helpful for Nostr Clients that use React Native (like Olas) or Web Clients (like noStrudel)

It wouldn't be as beneficial to native iOS clients (like Damus) and it would likely take some time to figure out

Would this be worthwhile?

nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qqszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fgfjtyk0 nostr:nprofile1qyxhwumn8ghj7e3h0ghxjme0qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qpql2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqta478g nostr:nprofile1qythwumn8ghj7enfd36x2u3wdehhxarj9emkjmn9qyt8wumn8ghj7enjv4h8xtnwdaehgu339e3k7mgqypl62m6ad932k83u6sjwwkxrqq4cve0hkrvdem5la83g34m4rtqegf4xfv5

#asknostr

nostr:nevent1qvzqqqqqqypzp0nntrz0u5q53nx2lspw5gzasq29uffc3x4rjkx6475xxuz8epqwqqs2lt0qckjcl6nffz35k7f9hylr0twe4x7wvg3acczerg69pf9cukgtdzy98

One thing they have in common.

Nostr.

Don’t build APIs.

What about SDKs?

nostr:note19t28p56sv6khf9kdxchmkfrvune3lf6d5adfy5yr8rk9urflekksm5s052