Skip to main content
← Back to list
01Issue
FeatureClosedSwamp ClubPublic
Assigneeskeeb

Relationships

#955 Giphy integration via /giphy command

Opened by keeb · 7/4/2026

Problem statement

Lab ripples and other composers are text-only. Sometimes the correct response to an issue is a GIF. Why not, right?

Proposed solution

Support a /giphy <search terms> command in composers (lab ripples at minimum). Typing /giphy party gator would search Giphy and insert a matching GIF into the message — either the top result or a small picker of results to choose from.

  • Slash command recognized in the composer, Slack/Discord style.
  • Renders the selected GIF inline in the posted ripple.
  • Needs a Giphy API key (env-gated like other integrations — unset key disables the feature gracefully).

Alternatives

  • Paste raw GIF URLs and render them inline (less fun, no search).
  • Support a generic slash-command framework first and make /giphy the pilot command.
  • Don't do it (but: why not, right?)
02Bog Flow
OPENTRIAGEDIN PROGRESSCLOSED+ 1 MOREASSIGNED+ 5 MOREREVIEWAPPROVAL

Closed

8/15/2026, 1:46:07 AM

No activity in this phase yet.

03Sludge Pulse
keeb assigned keeb8/14/2026, 10:04:32 PM
Editable. Press Enter to edit.

keeb commented 8/15/2026, 12:08:14 AM

Closing this — investigated rather than dismissed, so here is the whole reasoning.

The technical path is clear and cheap. Nothing blocks a GIF from rendering today. @deno/gfm's default sanitizer allows <img> with src from any host with no allowlist, https: is an allowed scheme, the app's CSP carries only frame-ancestors and sets no img-src, and .lab-md .markdown-body img { max-width: 100% } already exists. So ![](https://[HOST-1]/...) renders in a Lab ripple right now, and /giphy could have been a purely client-side text insertion with zero server render changes. The picker itself would be a close clone of the @-mention autocomplete, which is already factored into a pure core (lib/domain/mention/mention-autocomplete.ts) plus an island wrapper.

The blocker is the trade, not the effort. swamp-club has no image proxy — none anywhere; the only image infrastructure is OG generation, which produces images rather than proxying them. So an inserted Giphy URL is fetched from Giphy's CDN by every operative who opens that issue, every time, indefinitely. Giphy would receive the IP address, User-Agent and Referer of every viewer of that Lab issue, including operatives reading a private-collective issue.

Shipping a vendor picker would make swamp-club the author of that exposure rather than its passive host, and would make it routine rather than incidental. That is the judgement: the convenience is real — a search-and-insert picker is genuinely more useful than knowing a [HOST-1] URL, which is exactly why this was filed — and it is not worth being the party that introduces a third-party observer to the Lab.

The general case is now tracked separately. Any author can already paste a remote image URL, so the exposure exists whether or not /giphy ships. Citing it here while leaving that unexamined would have been inconsistent, so it has been filed on its own with three options (accept and document / proxy like GitHub's camo / restrict sources) and no recommendation attached — it is a product-security judgement.

Context worth recording: #64, the "reactions and Giphy integration in comments" issue this descends from, is already closed. And the surface has narrowed since filing — #844 removed feed comments, so Lab ripples are now the only user-authored composer.

What would change the answer: an image proxy or cache landing for another reason. After that, /giphy becomes a small, self-contained addition on top of it. Note also that a proxy is not the only mitigation — fetching the chosen GIF once and storing it would solve the exposure and fix GIF link rot in the same stroke. So this is a judgement about cost, not an impossibility.

Sign in to post a ripple.