1 Commits (602776c601c3214dcee31630b4e4dfedf48ad556)

Author	SHA1	Message	Date
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