6 Commits (60e865b9003e08db90bd604fe071f0dba87b94ff)

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
Strycher	006c365d25	feat(#282): send a Giphy URL instead of g:<code> for cross-client GIFs ... The picker emitted `g:<id>`, a convention that exists only in this Flutter client lineage's parseGif (inherited from upstream, not a MeshCore protocol feature). A recipient on stock or any non-lineage client has no way to expand it, so a GIF arrived as opaque text (#223). encodeGif now emits `https://giphy.com/gifs/<id>`, a form parseGif already matches, so: - stock clients receive a tappable URL they can actually open - Offband keeps rendering inline with no render-side change - legacy `g:<id>` payloads still decode, back-compat unchanged Cost is ~41B vs ~20B against a ~160B payload. A full message carrying sender prefix + reply mention + URL measures ~79B, roughly half the cap. Checked, and did NOT change, the outbound structured-payload guard in prepareContactOutboundText/prepareChannelOutboundText: Smaz.encodeIfSmaller declines to compress a URL (base64 overhead exceeds the dictionary gain) and Cyr2Lat passes unmapped ASCII through, so a GIF URL survives intact without widening the guard. Both pinned as regression tests instead. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	3 days ago
Strycher	edd9530c25	fix(#235): render inline @[Name] mention chips + reply-gifs ... Two shared-root render gaps (message tokens were only matched at fixed positions): - TranslatedMessageContent: parse @[Name] anywhere (leading, inline, or repeated) and render each as a chip; messages without a mention keep full link support (#233). - GifHelper.parseGif: strip a leading `@[Name] ` reply prefix before matching so a reply-with-gif resolves to the gif instead of literal text; arbitrary text before a gif is still left as text (#232). Tests: parseGif reply/format cases + widget tests for inline/leading/multiple mention chips. Full suite 402 green. Part of #233, #232. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	1 week ago
Enot (ded) Skelly	5354acb1d3	clean up after merge conflicts	3 months ago
Adam Novak	c5ec60638c	Put reaction and GIF helpers in charge of encoding	4 months ago
Adam Novak	75ec3b6116	Centralize GIF parsing in a helper like for reactions	4 months ago