Summary
Stickers should work like they do in WhatsApp: real image stickers, organised in packs, with the option to bring existing WhatsApp sticker packs into the app.
Current behaviour
The sticker picker shows four static SVG files that ship with the frontend, spark, heart, party and thumbs up. A sticker is sent as an encrypted message of kind sticker that carries only the sticker id, and the receiving client resolves that id against the same built in list. A sticker that the receiver does not know cannot be displayed.
Wanted behaviour
- Image stickers in packs instead of a fixed handful of built in graphics
- A picker that shows the installed packs and allows switching between them
- Import of WhatsApp sticker packs, which are WebP images with a pack metadata file
- Stickers that the recipient does not have installed still render correctly
Notes worth deciding early
The current protocol sends only an identifier, which works only for stickers that both sides already have. For user provided packs the image itself has to be available to the recipient. Options are to upload the sticker as an encrypted attachment like any other media, or to distribute packs separately and fall back to a placeholder when a pack is missing. This choice shapes the rest of the implementation, so it should be settled before the picker work starts.
Also worth checking: allowed formats and size limits, animated WebP support, and whether stickers should be stored per user or shared between users.
Related wish, tracked separately: a full emoji picker with search and categories.
Summary
Stickers should work like they do in WhatsApp: real image stickers, organised in packs, with the option to bring existing WhatsApp sticker packs into the app.
Current behaviour
The sticker picker shows four static SVG files that ship with the frontend, spark, heart, party and thumbs up. A sticker is sent as an encrypted message of kind sticker that carries only the sticker id, and the receiving client resolves that id against the same built in list. A sticker that the receiver does not know cannot be displayed.
Wanted behaviour
Notes worth deciding early
The current protocol sends only an identifier, which works only for stickers that both sides already have. For user provided packs the image itself has to be available to the recipient. Options are to upload the sticker as an encrypted attachment like any other media, or to distribute packs separately and fall back to a placeholder when a pack is missing. This choice shapes the rest of the implementation, so it should be settled before the picker work starts.
Also worth checking: allowed formats and size limits, animated WebP support, and whether stickers should be stored per user or shared between users.
Related wish, tracked separately: a full emoji picker with search and categories.