Gif-X Meme Maker

Search static or animated GIFs from a decentralized Nostr + IPFS index with web-search fallback, and insert them into X replies

The X.com GIF search engine is boring. This plugin amps up your experience on X by allowing you to pull images from the internet, cache them in a local IDB and/or pin them to IDFS for a decentralized experience. It also has a built in meme maker, meme vault for local store of memes you can make from images returned in your search. You can even right click on an image and add it to your meme box to make a meme later. All of this so you can easily post this into your replies on X. Add text to animated gifs Add text static images Rotate text Layered canvas editing Lasso tool Magic wand tool Shape lasso tool Gif animation frame selection for targeted meme making Full GIF Animation editing and encoding Callout bubbles Pin to IDFS Pin to local Preview original size Scrolling Screen Capture Search feature You want this! No more making memes using a third party tool, logging in, blah de blah de blah.. Grab this tool.. search, meme, post.. Your new GIF experience is injected into the X UI! How it works TECH NERD TIME: How are search terms tied to looking up images? The connection is through a normalized queryKey that is stored alongside every archived GIF. Here is the full flow: You type a search term. Settings.normalizeQuery(query) normalizes it (lowercase, trimmed, etc.) to produce a queryKey. Tier 1 — Local index: LocalGifIndex.search(queryKey, limit) does an exact match — it filters records in chrome.storage.local where record.queryKey === queryKey (lib/localindex.js line 17). These are GIFs you previously archived under that exact term. Tier 2 — Global Nostr index: gifIndex.query(queryKey, limit, ...) queries Nostr relays for GIFs that other users published under that search term (background.js line 526). The queryKey is used as the Nostr tag/filter. Tier 3 — Web engine (Bing/Brave/etc.): If the first two tiers do not fill the result limit, a live web image search fires for the original query string (background.js lines 573–583). Results from this tier get enqueued for archiving, which stores them in the local index and publishes them to Nostr under the same queryKey — so future searches by you or anyone else on the relay will find them through tiers 1 or 2 instead. In short: the search term is stored verbatim (normalized) as a tag on every GIF record. Future lookups are exact-match on that tag, not full-text search across titles or metadata. If you search "funny cats" and later search "funny cat" (no s), those are two different queryKey values and will not share results from the local or Nostr index.