1 Commits (4ab744ddfe921ea16fc7ae73dee596325fb883c4)

Author	SHA1	Message	Date
Strycher	5b23549054	feat(#283): render pasted Giphy/Tenor URLs inline behind a host allowlist ... Pasted GIF links rendered as plain text because parseGif only matched the compact forms. Adds GifHelper.resolveGifUrl, which maps any supported payload to the URL that renders it, and widens coverage to the links people actually paste. Allowlist is deliberately narrow, Giphy and Tenor only. Off-list URLs return null and stay plain tap-to-open links, never auto-fetched: auto-loading a stranger's URL leaks the viewer's IP and enables tracking-pixel abuse, and inline-rendering unmoderated hosts is a malware and inappropriate-content vector. Tests pin the rejections, including a lookalike host (giphy.com.evil.example) and a general image host (imgur). Newly rendered: - i.giphy.com/<id>.gif and .webp, the form a browser copy produces - media.tenor.com and c.tenor.com direct assets A tenor.com/view/<slug>-<id> PAGE url is deliberately NOT matched. The modern Tenor CDN path uses an opaque hash that cannot be derived from the page id, so resolving one requires the Tenor API and a key. Such a link stays plain rather than silently rendering the wrong image. Supporting it is a separate decision. Also removes the hardcoded 'https://media.giphy.com/media/$gifId/giphy.gif' literal duplicated across all four render call sites. That duplication is the same drift that caused the #284 notification regression, where a second hand-rolled copy of GIF detection went stale. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2 days ago