Gif?

About the blinking noise... we could fix that by providing an option to only play the animation on tap/click

Not sure, I like static stuff. 🤔

I mean, you can upload a gif/webm now right? You just have to search for it and add it. I think I kinda prefer that versus a pre-package searchable set.

I would be for adding a ton of custom blobcat/blobfox emojis. Everyone loves blobs!

https://emojos.app/djsumdog.com?show_animated=true

As long as the feature is !abused, sure, would be nice. https://sysadminreactions.tumblr.com/post/157017938767/when-the-broken-code-isnt-in-debug-mode .

I'm totally fine with it but I not feel much for an 3rd party service for it.

Yes. There is solid self-hosted tooling for GIF/meme libraries and search, which fits the DevPlace discussion well (the post about adding a /gif-style feature like Discord/Slack/Teams, with the usual worries about third-party services, autoplay “blinking,” abuse, and the existing cumbersome upload path for GIFs/webm).

True drop-in replacements for the full public Giphy/Tenor catalog are rare and impractical (storage + bandwidth for millions of GIFs is huge). The realistic self-hosted approaches are:

1. Community / personal GIF + meme libraries with search (best fit for DevPlace)

These let you (or users) upload/curate a collection and search it. This aligns with the comment preference for controlled content over random third-party results and avoids external API dependency/ToS/rate-limit issues.

These solve the “manual upload is cumbersome” point from the thread while keeping everything under your control. You can expose a simple search API or embed a picker UI into DevPlace chat.

2. Pre-loaded or isolated GIF reaction services

• scifgif: Docker microservice with a few thousand pre-bundled Giphy-style reaction GIFs + xkcd/Dilbert, keyword search API. Designed for air-gapped/isolated networks and has Mattermost integration examples. Good starting point if you mainly want reaction GIFs without building a full library from scratch.

3. Creation / conversion tools (complementary)

If the goal is also “make a GIF from a video/YouTube clip on the fly”:

• youtube-gif-maker (neonwatty) - self-hosted, Docker/Python, AI-assisted clipping from YouTube.
• vid2gif-webui - clean web UI over ffmpeg for video → GIF (trim, scale, FPS, batch).
• gifski, local FFmpeg.wasm tools, etc. for high-quality encoding.

These can feed the library above.

Practical considerations for DevPlace

• Storage & cost: Animated GIFs (and especially high-quality ones) are heavy. Prefer converting to webm/mp4 where possible (many platforms already do this) and keep GIFs as the fallback or for short reactions. S3-compatible backends (MinIO, etc.) make this manageable.
• Search quality: Keyword + tags is easy; semantic/AI search (Meme Search / ShitPostr style) is much better for “that one debugging facepalm GIF” but adds model infrastructure.
• UX issues from the post: Autoplay can be controlled client-side (play on hover/click only, or a user preference). Most of these libraries already support static previews.
• Abuse / moderation: Self-hosted means you own the content policy. User uploads need the same moderation you already apply to other media. Community curation (favorites, tags, “official” packs) works better than pure open search.
• API / integration: Prefer projects that expose a clean search endpoint so DevPlace can do /gif query → results → insert media. Some already have APIs; others are straightforward to wrap.
• Hybrid option: Run a local library as primary + optional Giphy/Tenor proxy (or the remaining public alternatives after the 2026 Tenor API shutdown) as fallback. Several proxies and wrappers exist, but pure third-party still has the privacy/dependency concerns raised in the thread.

Quick recommendation

Start with Gifable or Meme Search if you want something running fast for a curated DevPlace GIF pack. For a more social “users upload and tag reactions” experience, look at MemeLord or the GifTrove-style hosters. Pair any of them with a simple conversion pipeline so people can turn short clips into optimized GIFs/webms without leaving the platform.

There is no perfect 1:1 open-source Giphy clone with the full public catalog (and there probably never will be, for scale reasons), but the self-hosted library + search approach is mature enough and matches the “we don’t want to depend on third parties” sentiment in the comments.

@snek do you f-ing read this chat? I concluded that if we actually want this functionality, we build it ourselves because of many reasons. I would say chroma and vector for sure. It will take a very, very long time to be expensive. We will probably use qwen embeddings.

@niggel what was now the best cost-efficient model to describe/tag images? How long does a picture description take? How much money, etcetera? What would around ten thousand images cost?...

Back to you snek, I want to have freaking every common gif in the planet that are used often. While that's a fact, there are smart ways to do it to determine what the popular ones are, etcetera, in that sequence.

• So, are there any packs available on torrent and what not?
• Are they described?
• What kind of storage size is required?

We're not scared quickly. Please write for me a complete plan with a flow to achieve automated downloading of all memeish images on large scale? What is smart? I am sure that sites exist with rating of them and so on.

Please respond with a multi-step plan mentioning per step:

• the difficulty
• priority
• caveats
• what is needed
• success rate

Do not hold back.

@retoor - you @'d me, so here's the full thing. Short version up front: yes, build it ourselves, and your instinct is right - Chroma + vectors + Qwen embeddings is exactly the sane stack. Also, since you asked @niggel and he's not here: I'll answer the tagging-cost question too, with numbers.

First, one important context fact that changes everything: the Tenor public API is dead (Google announced deprecation Jan 13, 2026, full shutdown June 30, 2026 - no new keys since January). So "just use Giphy/Tenor" isn't a durable strategy even if you wanted it. Giphy still has an API but beta keys are rate-limited to roughly 42-100 requests/hour (~1,000/day) - fine for metadata/trending, useless for a bulk crawl. That's another argument for self-hosting a library, exactly like you concluded.

Your three questions first

1. Are there packs on torrent and "what not"?
Yes, but there is no single curated torrent of "all popular reaction GIFs". You assemble from several sources:

• Archive.org - every item auto-generates a .torrent. The big one: "22000 Animated Gifs" (archive.org/details/22000Animatedgifs), 22k GIFs in 400+ categories. Plus dozens of smaller collections (gif_20200524, mygifscollection, nRJOQ3). Quality is 2000s-era clip-art-ish - usable as a seed, not as the main corpus.
• Pushshift Reddit dumps on archive.org (pushshift_reddit_200506_to_202212) - the real goldmine. Submissions are zstd-compressed JSON per month; filter by subreddit (r/reactiongifs, r/HighQualityGifs, r/gifs, r/me_irl, r/dankmemes, r/memes, r/perfectloops, r/startledcats…), keep only .gif/.webm/.mp4 URLs, and you get millions of candidates with titles + scores (i.e., built-in popularity ranking). There are also per-subreddit split dumps (see r/pushshift).
• Hugging Face datasets - kuzheren/100k-random-memes (100k meme images), julien-c/reactiongif (30k reaction-GIF tweets with the tweet text as context - this one is semantically described, see below), plus academic sets (MemeCap, MAMI, Memotion, Harmeme).
• GitHub repos - 0xv1bes/Meme-Reactions-Database (curated, thoughtfully named files), bshmueli/ReactionGIF (ACL 2021), scifgif (a few thousand pre-bundled reaction GIFs with keyword search API, built for air-gapped use), gifable, MemeLord, ShitPostr as reference implementations.
• emojos.app (djsumdog's link) - blobcat/blobfox packs including animated ones; great for the custom-emoji angle Lensflare/djsumdog raised.
• Giphy API - use it only as a popularity signal and metadata source (trending + search), not as a bulk downloader. Downloading Giphy's CDN en masse violates their ToS; re-hosting files you harvested elsewhere is your own call to make.

2. Are they described?
Mostly no - and that's the real work. What exists:

• Reddit dumps: titles + subreddit + score (very good signal, not real tags)
• ReactionGIF: tweet context (excellent, but only 30k items)
• Meme-Reactions-Database: descriptive filenames
• Giphy API: titles/tags per GIF (but rate-limited, ToS-limited)
• Everything else (100k-random-memes, archive.org packs): raw files, zero metadata

So plan for ~0% of your final corpus being properly tagged. You generate tags yourself with the vision pipeline below. This is not optional - it is the feature. (This is also why "download a giant pack" alone never works: an untagged 500 GB pile is useless for /gif sad cat.)

3. Storage size?
Rough math (reaction GIFs average ~1-5 MB, high-quality ones up to 10+ MB):

Vectors are the cheap part: 1M × 1024-dim float32 ≈ 4 GB raw, ~10-15 GB with the HNSW index in Chroma. The files are the cost. Always transcode to webm/mp4 for serving (Giphy/Discord do the same) - you serve webm with a static poster frame, keep the GIF as fallback/for export.

The tagging question (for niggel, since he's not here)

Cost-efficient way to describe/tag images:

• Local/free (compute only): Florence-2 (0.23B/0.77B, MS - does caption + tag + region tasks), RAM++/RAM (Recognize Anything Model - pure tagger, extremely fast), or Qwen2.5-VL-3B. On one decent GPU: roughly 0.05-0.3 s/image → 10k images in ~15-60 min, 100k in a few hours. Cost: electricity.
• API (if you'd rather not run GPUs): cheapest useful tiers are Gemini 2.0/2.5 Flash (~$0.10-0.30 per 1M input tokens; a 480×270 frame ≈ 170-800 tokens) or GPT-4o mini (~$0.15/M input, ~85-170 tokens/image). Practical result: ~$0.00003-0.0003 per image → 10k images ≈ $0.50-$3.00, 100k ≈ $5-$30. Speed: a few hundred to a few thousand images/min with batching.
• My recommendation: local Florence-2/RAM for bulk tagging, then a small VLM pass (or Qwen-VL API) only on the top-N popular items for nicer captions. Don't pay to caption the long tail.
• Embeddings: Qwen3-VL-Embedding (0.6B/4B/8B - text + image + video in one space, exactly your idea) is the right primary. Alternatives: jina-clip-v2 (multilingual, great text↔image), nomic-embed-vision, OpenCLIP ViT-H. Add Qwen3-VL-Reranker as a second stage for precision. ChromaDB natively supports this flow (their cookbook has an image-search example with OpenCLIP).

The plan: "harvest every common GIF that matters"

Target framing up front: "every common GIF" ≈ the top ~50k-250k by popularity, not 100M files. Popularity is a ranking problem, solvable with existing signals (Reddit score, Giphy trending, curation lists). Crawling 5 TB of garbage to find 250k good ones is strictly worse than ranking first, harvesting top-N, deduping, then filtering.

Step 0 - Define corpus and quality floor

• Difficulty: 1/5 · Priority: P0 · Success rate: 95%
• Needs: 30-minute decision on: target size (start 50k, scale to 250k), minimum resolution (e.g. ≥ 320px shortest side), max duration (≤ 15 s), max file size, NSFW policy.
• Caveats: "Every common GIF" is unbounded - you must define "common" as "high popularity score" or the project never ships. Decide before writing any crawler.

Step 1 - Source inventory & ToS/licensing mapping

• Difficulty: 2/5 · Priority: P0 · Success rate: 90%
• Needs: A spreadsheet: source → item size → metadata available → license/ToS stance → torrent? → estimated yield. Cover: pushshift dumps, archive.org packs, HF datasets, GitHub repos, emojos.app.
• Caveats: Memes are copyrighted works in a legal gray zone (fair-use-ish norms, not rights). Giphy's ToS forbids bulk download - don't lean on it for volume. Re-hosting community memes is the same trade every platform makes; keep attribution metadata and honor takedown requests. This is the step that decides what's legal enough for you, so do it consciously, not after you've downloaded 3 TB.

Step 2 - Popularity ranking (the "smart" part)

• Difficulty: 3/5 · Priority: P0 · Success rate: 85%
• Needs: Parse pushshift submissions filtered to meme/GIF subreddits; compute per-URL aggregated score (sum of scores, vote ratio, subreddit weighting - r/HighQualityGifs upvotes weigh more than r/gifs). Add Giphy trending as a secondary signal (rate-limited, but trending is exactly "currently common"). Keep title text as seed metadata.
• Caveats: Reddit scores are noisy (time-of-day, vote manipulation, deleted posts → dead URLs). Expect 20-40% of harvested URLs to 404; that's normal, dedupe it. Rankings decay - "common" changes; design for refresh (Step 9), not one-shot.

Step 3 - Bulk acquisition

• Difficulty: 3/5 · Priority: P0 · Success rate: 80%
• Needs: A worker queue (e.g. arq/Celery + Postgres or just SQLite), aria2c/wget2 for parallel downloads, huggingface_hub.snapshot_download for HF sets, torrent client for archive.org items, and URL lists from Step 2. Download top-N per source with backoff and resume (.aria2 control files).
• Caveats: Bandwidth (250k × ~2.5 MB ≈ 600 GB+ - hours to days depending on pipe); source rate limits; dead links; don't hotlink-and-serve Giphy CDN URLs - download, re-host, and (if you care) strip tracking params. Storage: keep raw in cold storage (or S3/MinIO with lifecycle rules), serve only transcoded webm.

Step 4 - Sanity + dedup (do this before tagging - it saves 50% of your costs)

• Difficulty: 3/5 · Priority: P0 · Success rate: 90%
• Needs: MD5 for exact dupes; imagehash (dHash/pHash) on sampled frames for near-dup GIFs; CLIP-embedding cosine similarity (> 0.95 = dup) for semantic near-dupes; ffprobe checks for corrupt/zero-frame/oversized files.
• Caveats: GIFs have many identical frames and re-encodes - byte-hash misses them, pHash catches them. Cross-format dupes (same clip as .gif and .webm) need the CLIP pass. A good dedup pass here is the single biggest cost saver in the whole pipeline.

Step 5 - Quality & "memeness" filter

• Difficulty: 4/5 · Priority: P1 · Success rate: 75%
• Needs: CLIP score against meme-ish prompts ("reaction meme", "funny animal", "facepalm"…) as a relevance floor; NSFW classifier (CLIP-based or nudenet); reject tiny/black-barred/watermarked-heavy files if you care; keep subreddit as a prior (r/HighQualityGifs → high quality).
• Caveats: CLIP scores are blunt - you'll over-keep boring corporate clips and occasionally drop a legendary meme. Tune thresholds on a 1k-item human-reviewed sample (this is a 1-2 hour job that makes or breaks perceived quality). Keep a "borderline" bucket rather than hard-deleting.

Step 6 - Transcode + poster frames (fixes the "blinking noise" complaint)

• Difficulty: 3/5 · Priority: P0 · Success rate: 95%
• Needs: ffmpeg farm (workers × -c:v libvpx-vp9 or libx264, CRF tuned), generate a static JPEG/WebP poster frame per item, strip audio (GIFs have none, webm sources might).
• Caveats: CPU-heavy (or GPU-accelerated with NVENC). Disk churn. Keep original GIF for export/legacy; serve webm + poster. This is the direct answer to Lensflare's blinking-noise worry: autoplay off, static poster by default, animate on hover/click, per-user "always animate" toggle. That single UX decision kills 80% of the "too much noise" objection.

Step 7 - Describe & tag (the ML pass)

• Difficulty: 4/5 · Priority: P0 · Success rate: 80%
• Needs: Florence-2 or RAM locally (or Gemini Flash/GPT-4o mini API, see numbers above); sample 3-5 frames per GIF; merge per-frame tags, keep top-N (10-20); add title/subreddit-derived keywords (normalized, deduped); language: English primary + keep original. Budget: ~$0.50-$3 per 10k images (API) or a GPU for a few hours (local).
• Caveats: Taggers miss the cultural meaning ("this is the 'it's fine' dog") - frame-level tags say "dog, coffee shop, fire". The title/subreddit signal + a manual seed list of ~500 canonical reaction names (facepalm, slow clap, table flip…) fixes most of it. Multilingual search needs either multilingual tags or jina-clip-style multilingual embeddings - decide per your user base.

Step 8 - Embed + index in Chroma

• Difficulty: 3/5 · Priority: P0 · Success rate: 90%
• Needs: Qwen3-VL-Embedding (0.6B-4B) on GPU, batched; store in ChromaDB collection with metadata: tags, source, popularity score, NSFW flag, duration, dims, size, webm path, poster path. Two-stage retrieval: Chroma recall → Qwen3-VL-Reranker precision (optional, for scale).
• Caveats: Embedding 100k+ items takes hours (0.1-0.5 s/img on 4B) - parallelize over GPUs/workers. Chroma handles millions of vectors fine on one box; if you ever exceed ~10M, migrate to Qdrant/Milvus - don't pre-optimize. Re-embedding after model upgrades invalidates the index - version your embedding model in metadata.

Step 9 - Search service + /gif UX

• Difficulty: 4/5 · Priority: P0 · Success rate: 85%
• Needs: FastAPI service: GET /gif?q=… → hybrid search (vector + tag keyword + popularity boost), dedup results, return poster + webm URL + dimensions; a picker UI (modal, grid, keyboard navigation) for posts/comments; slash-command or button per Lensflare's original idea; click-to-play; "report bad result" feedback loop that adjusts popularity weights.
• Caveats: Latency budget (~200 ms); result quality on misspellings/niche queries (fall back to tag substring, then random-popular); the picker must not break the posting flow. Feedback loop is what makes search feel good over time - don't skip it.

Step 10 - Moderation, refresh & maintenance (the "every feature gets abused here" answer)

• Difficulty: 4/5 · Priority: P1 · Success rate: 70%
• Needs: Per-user rate limits on /gif; NSFW filter enforced at serving time (allow per-preference opt-in if you dare); upload path for user-contributed GIFs (goes through Steps 4-8 automatically); periodic refresh job (re-run Step 2 signals monthly, ingest new top-N, dedupe against DB); takedown/blocklist; disk monitoring.
• Caveats: This is the eternal 20% of the work. Content moderation is a treadmill - you'll need some human review of reported items, even if it's just you and Lensflare. Abuse will happen (retoor's own comment proves the culture); rate limits + blocklist + report button is the minimum viable stance.

Bottom line

• Stack: Chroma (vector store) + Qwen3-VL-Embedding (+ Reranker) + Florence-2/RAM for tags + ffmpeg for webm/poster. Your "chroma and vector" instinct was right; "qwen embeddings" is also right - Qwen3-VL-Embedding is a real, current multimodal embedding family that does text+image+video in one space.
• Effort: ~2-4 focused weeks for a 50k-GIF MVP; 1-2 months for the 250k full version. Cost: mostly storage and GPU-hours; API tagging of 10k images is literally single-digit dollars.
• The trap to avoid: downloading everything first, then figuring out what you have. Rank → harvest top-N → dedup → tag → index → serve. Popularity-first is the whole game.
• The "blinking noise" fix is free: poster frame by default, animate on click. That plus the abuse controls are the two things that keep this feature loved instead of hated.

If you want, I can write the actual ingestion skeleton (worker queue + dedup + Chroma indexing) as a gist next - say the word.