CraysGIF Buddy
GIF Buddy is Lemon's GIF companion for Nostr clients: it searches Tenor, uploads media through nostr.build and publishes NIP-94 file metadata so GIFs can become searchable Nostr objects.
The joke is infrastructure
GIF Buddy is the kind of Nostr app that is easy to underestimate because the surface is intentionally silly. You open a page, type a phrase, search for a reaction GIF, and send something that makes a conversation feel less stiff. That sounds minor until you remember how social media really works. A large part of online culture is not made of essays. It is made of timing, tiny loops, weird facial expressions, private jokes, memes, screenshots, stickers and the little fragments people use when a plain sentence would be too dry.
On closed networks, those fragments live inside the platform's own media system. The platform knows the search index, the asset URL, the ranking, the copyright pipeline, the moderation rules and the analytics. If the network changes direction, shuts off an API or decides a creator's account no longer belongs there, the expressive layer moves with it. That is why GIF Buddy matters more than its name suggests. It asks a practical Nostr question: can a client reach into the big outside GIF world, bring a piece of media back, and describe it in a way that other Nostr software can understand?
NostrApps describes the project with the short phrase "Nostrify gifs" and calls out three jobs: making GIFs from the external world available inside Nostr clients, uploading GIFs, and searching external GIF libraries. That is the plain version. The deeper version is more interesting. GIF Buddy is a bridge between a familiar media habit and Nostr's event model. It does not try to become the whole social client. It sits beside clients and says: here is the file, here is the metadata, here is the hash, here is a relay where this object can be found.
That is useful because GIFs are not just decoration. They are part of how people speak. If Nostr wants to be more than a place where protocol people post austere text notes to each other, the fun layer has to be portable too. GIF Buddy is one small attempt to make that layer less dependent on a single app's database.
What happens when you press the GIF button
The public app at gifbuddy.lol gives you the ordinary front door: search, browse, choose, upload, look through Nostr GIFs, keep favorites and work with collections. The code shows how the trick is built. GIF Buddy is a Python Flask application. It has routes for the main GIF search, a dedicated Nostr search page at /nostr, upload flows, a collection page, favorites, an API page and a decode tool. It also ships as a progressive web app, with manifest files and icon sets in the static assets.
For outside GIF search, the project uses Tenor's API. The gifsearch.py module calls Tenor's v2 search endpoint, requests animated GIF formats and sticker-style media, and returns the pieces a front end needs: GIF URL, dimensions, preview image, thumbnail and content description. So the first half of GIF Buddy is recognizably normal web software. A user searches a term. The server fetches matching GIF candidates. The browser shows them.
The second half is where the Nostr part begins. When a selected GIF needs to become a Nostr object, GIF Buddy does not merely paste a Tenor URL and call it a day. Its upload path can pass media through nostr.build's NIP-96 upload API. The app prepares a NIP-98 HTTP authorization event, encodes it into the request header, uploads the file or URL, receives the returned file metadata, and then publishes a NIP-94 event. In other words: GIF Buddy turns a search result into a signed, relay-published file metadata object.
If you are reading this as a normal user, keep the picture simple. First, GIF Buddy helps you find the thing. Then it tries to store or reference the thing in a Nostr-friendly way. Then it publishes an event that other software can search and interpret. That is the difference between "I pasted a random media URL" and "there is a Nostr event describing this media object."
The NIP-94 move
The technical center of GIF Buddy is NIP-94. NIP-94 defines kind 1063 file metadata events. A file metadata event can carry URLs, MIME type, file size, dimensions, SHA-256 hashes, thumbnails, blurhash-style preview data, summary text and alt text. That matters because clients can read a structured event instead of guessing what a bare link might be.
GIF Buddy's nip94.py builds these kind 1063 events. The tags it prepares include url, m for MIME type, x and ox for hashes, size, dim, thumb, image, summary and alt. For GIFs, the project adds GIF Buddy's own context. The NIP-98 upload helper can tag GIF objects with gifbuddy, and the meme side can use memeamigo. The search code then knows how to filter and retrieve these objects from GIF Buddy's relay.
The relay is part of the design. The app uses wss://relay.gifbuddy.lol as the home relay for the published media metadata. The Nostr search code filters kind 1063 events, looks for the GIF MIME type or project tags, and can deduplicate results by hash. It also uses the Nostr SDK and has code for Negentropy-style reconciliation to keep the local event cache in sync with the relay. That is a surprisingly serious amount of machinery for an app that greets you with GIF search.
The practical result is this: a Nostr client does not need to invent a GIF database from nothing. If it understands NIP-94 events and knows where to look, it can discover media that GIF Buddy has already described. The quality of that experience depends on the client, the relay and the continued operation of the service, but the shape is right. GIF Buddy is not just attaching vibes to notes. It is publishing file metadata into the network.
Lemon and the codebase
The project trail points to Lemon, the GitHub user happylemonprogramming. The public repository is happylemonprogramming/gifbuddy, described as "A gif companion app for nostr clients." GitHub metadata shows it as a small, active public project rather than a large company product: created in August 2024, updated in 2026, a handful of stars, one fork, and no open issues at the time checked. The contributor view is essentially Lemon's work.
That matters for how you should read the app. GIF Buddy is not pretending to be a polished enterprise media platform. It is a maker's tool with production ambitions. The repository has the signs you would expect from a living single-builder project: direct Flask routes, utility modules split by protocol job, data files in the repo, API endpoints, deployment traces and pieces that clearly grew as the product grew. Some people will find that messy. In the Nostr world, it is also familiar. Many of the useful tools begin as one person's itch made public.
The stack is not mysterious. Flask handles the web app. nostr-sdk and related crypto libraries handle Nostr event work. pynostr, coincurve, cryptography, Pillow, OpenCV, NumPy, scikit-learn, FAISS, Stripe and other packages appear in the requirements, because the app reaches beyond a simple search page into images, decoding, payments, media manipulation and indexing. The repo also contains modules named nip94.py, nip96.py, nip98.py, publish.py, nostrgifsearch.py and event_database.py. The filenames tell the story before you even read the functions.
There is one important caution for builders: the GitHub metadata does not show an explicit license. That does not make the app unusable as a service, but it does matter if you are thinking about copying, remixing or shipping code from the repository. Treat the website as a public app, treat the code as visible research material, and check permission before assuming you can reuse it commercially.
Not only GIFs
GIF Buddy has a sibling mood inside the same codebase: Meme Amigo. The Flask routes include meme search, meme templates, meme captioning, meme GIF creation, image creation, background removal and decode tools. There are database files for GIF events, meme events and uploads. The app can search Nostr metadata for uploaded media, GIFs and memes, and it can expose counters and trending-style endpoints. It is less a single button than a small media workbench.
That broader shape is worth noticing because it shows the product instinct. Lemon is not only solving "I need a GIF right now." The code is circling a bigger question: what would a portable Nostr media layer feel like if normal people could use it without reading NIPs first? Search is one door. Upload is another. Favorites and collections are another. Meme creation is another. The API page is another. None of those doors is the whole house, but together they point at a practical media companion for clients that do not want to build every media workflow themselves.
This is also where GIF Buddy becomes most relevant for creators. If you make culture on the internet, you already know the pain: the clip, meme, reaction image or visual joke spreads faster than the source, and the platform that hosts it often owns the context. NIP-94 cannot magically solve attribution, copyright or storage economics. But structured metadata can at least give software better handles: hashes, URLs, alt text, thumbnails and relay-discoverable events. A small app that gets users to create those handles is doing more than decorating timelines.
The dependency chain
Read GIF Buddy honestly and you can see the dependency chain. Tenor provides a large outside GIF search surface. nostr.build provides the NIP-96-style upload target. NIP-98 handles the signed HTTP authorization story. GIF Buddy publishes NIP-94 file metadata. wss://relay.gifbuddy.lol acts as the focused relay. Clients and users consume the result if they know what they are looking at.
That chain is not a flaw by itself. It is how a lot of useful open-web software actually works. But it is a chain, and every link matters. If Tenor changes access, search can change. If nostr.build changes storage rules, uploads can change. If GIF Buddy's relay is unavailable, discovery can suffer. If a client ignores NIP-94, the structured event may exist but remain invisible in that client. If media rights become contested, the fact that something is referenced by a Nostr event does not erase the usual legal and ethical questions around media reuse.
The adult way to use GIF Buddy is not to worship it as "decentralized" because it touches Nostr. The adult way is to understand exactly what it decentralizes and what it does not. It decentralizes part of the media description layer by publishing signed metadata events. It can make GIF objects discoverable outside one client. It does not make Tenor disappear. It does not guarantee permanent file hosting. It does not turn every image into fair use. That clarity makes the app more interesting, not less.
Why it matters
The best Nostr apps often teach the protocol through a concrete action. A signer teaches you what private-key custody feels like. A relay browser teaches you that relays are not abstract pipes. A client teaches you how feeds, follows and replies are just event choices. GIF Buddy teaches a smaller but very human lesson: media is part of speech, and speech portability is weaker if the media layer remains trapped somewhere else.
If you are a user, try GIF Buddy when you want a playful action that still has technical substance. Search a GIF. Open the Nostr side. Look at what the app publishes. See whether another tool can find the metadata. You do not need to become a protocol engineer, but you will understand Nostr better if you can feel the route from search result to media object to relay event.
If you are a builder, GIF Buddy is worth reading because it shows a service-shaped Nostr app rather than another full timeline client. It uses existing outside infrastructure, wraps it in Nostr events and creates a specialized index around one behavior. That pattern can be reused for many categories: audio snippets, stickers, product images, venue media, article illustrations, receipts, documents and anything else where the file itself is not enough. The file needs metadata. The metadata needs a place to live. GIF Buddy is Lemon's compact answer for GIF culture.
Sources worth opening
These are the public trails used for this page: the live product, the directory listing, the GitHub repository, the protocol files and the main source files that show how the media path is wired.
- GIF Buddy official app
- GIF Buddy Nostr search
- NostrApps listing for GIF Buddy
- happylemonprogramming/gifbuddy GitHub repository
- GIF Buddy app.py routes and background jobs
- GIF Buddy Tenor search code
- GIF Buddy Nostr GIF search code
- GIF Buddy NIP-94 event builder
- GIF Buddy NIP-96 upload helper
- GIF Buddy NIP-98 auth and decentralize helpers
- GIF Buddy Nostr publishing helper
- GIF Buddy Python requirements
- Lemon on GitHub
- NIP-94 File Metadata
- NIP-96 HTTP File Storage Integration
- NIP-98 HTTP Auth
- Public Nostr profile trail for Lemon
- NIP-25 reactions
- NIP-27 text note references
- Nostr protocol NIPs repository
- NIP-01 basic protocol flow
- NIP-05 DNS identifiers
- NIP-07 browser signer capability
- NIP-10 text note threading
- NIP-11 relay information document
