Add support for displaying gzipped lottie (e.g. tgs)

[mohsenasm]

Description

Hi,
This PR adds support for displaying gzipped Lottie files, such as .tgs (Telegram sticker) files.

Demo video:

How it works

Gzipped files begin with a fixed byte sequence (1f 8b), which distinguishes them from standard image formats (PNG, WebP, JPG). The implementation detects this signature in the file header and automatically decompresses gzipped content before parsing it as Lottie JSON. If parsing succeeds, the decompressed animation is passed to the Lottie player.

To test this feature, download and unzip AnimatedSticker.tgs.zip, then send it as m.image or m.sticker.

What I have tested

• Works as m.image, m.sticker, and inline emoji on Chrome
• Works as m.image and m.sticker on Safari
• Functions correctly in sticker and emoji picker on both browsers

Next steps

• Fix inline Lottie emoji width on Safari
• Respect autoplayStickers setting when rendering stickers (set autoplay={false} in DotLottieReact)
• Respect autoplayEmojis setting when rendering emojis (set autoplay={false} in DotLottieReact)

---

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings

AI disclosure:

• Partially AI assisted (clarify which code was AI assisted and briefly explain what it does).
• Fully AI generated (explain what all the generated code does in moderate detail).

[mohsenasm]

In the past week, I had to merge 509 commits. Some lint and typecheck issues from Sable/dev seem to have come over into my branch after the merge. Should this be fixed in my branch, @hazre @7w1 ?

[7w1]

Yes, please do. It looks like those lint and merge errors are just a slightly messed up merge in Bookmarks.tsx with some duplicate lines

[mohsenasm]

After the merge, some animated stickers no longer work (those with "type": "m.sticker"). I suspect this line is the cause:

Sable/src/app/components/message/content/ImageContent.tsx

Line 160 in 444f2fc

return mxcUrlToHttp(mx, url, useAuthentication, 800, 600, 'scale') ?? undefined;

It asks the homeserver to scale stickers, but the server can't scale Lottie. We can see that in the logs:

Cannot find any thumbnails for the requested media ('/_matrix/client/v1/media/thumbnail/...').
This might mean the media is not a supported_media_format=(image/jpeg, image/jpg, image/webp, image/gif, image/png) or that thumbnailing failed for some other reason. (Dynamic thumbnails are disabled on this server.)

What should we do? Should we fallback to the original download url when thumbnail is not available? @7w1

---

This is fixed when I change the line to:

return mxcUrlToHttp(mx, url, useAuthentication) ?? undefined;

Why do we use a thumbnail when displaying stickers in room, but the full image in the sticker picker?

[7w1]

You're right, it probably shouldn't have been changed there. I changed it in #1286 so if you merge/rebase on the latest it should finally work

[mohsenasm]

Thanks. It's fixed now. @7w1

[7w1]

Hey, I'm doing some cleanup on your pr and it'll be merged at some point. There's a few issues I still need to fix, namely better mime type classification, some form of max size, and just testing coverage and making sure normal media isn't broken.

[mohsenasm]

Hi, after your changes, animated stickers with "type": "m.sticker" and emote icons no longer work.

Please test your changes by sending an m.sticker event with a .tgs file (unzip it and use the mxc from AnimatedSticker.tgs.zip).

My code wasn’t sensitive to the mimetype, although I use image/tgs in my events. We don’t check the mimetype when displaying image/jpeg, so I think we don’t need to do it here either. We can verify the file is gzipped from the header and parse the JSON to confirm it’s Lottie, which also seems reasonably efficient.

[7w1]

I’ll fix that tomorrow (or you’re welcome to). We can just add that detection as a fallback for when the normal image tags fail to load. I wanted to prefer using mime types when possible just because it’s a nonstandard image type.