Stickers, simplified

Feature Proposal
1

by recent efforts, all UIs can now display many sticker types as such, even animated ones. it seems to be time to think about how sending stickers can be improved in UI.

in the past, thinking about stickers was mostly around “sticker packs”, their format (own? existing?), how they can be created and identified (hash? changes in packs?) and how they can be distributed (track packs sent to recipients?, send then references?, low-res fallbacks? …)

all in all, many things to solve, so nothing of all that find their way into code.

time for an easier approach. @link2xt posted lately somewhere the idea, to avoid the problem of distribution by simply collecting all stickers one have ever seen and show them in a selector. no sticker packs.

i think, this is a good, pragmatic approach to move forward.

also, that lowers the barriers to create own stickers, eg. we can have an image-option “Use as sticker” and i also like removing the need to create whole packs when one has only one good sticker.

to make that more concrete, a minimal implementation:

  1. UI-wise, we would need a selector, typical Sticker-UIs have lots of tabs here (“Recently used” (showing the ones you sent out) and one for each installed pack). we would need only two tabs (“Recently used” and “All”).
    Desktop/Android already have selectors, they are disabled only. iOS would need sth.

  2. API-wise, we would need sth. as
    array = dc_get_stickers(context, DC_STICKERS_RECENT|ALL);
    there are some implementation details, of course, eg. what about multi-account, delete/add stickers manually, probably more - but not all is needed for a minimal implementation.

  3. core should have a dozen or so predefined stickers, so “All” is never empty on new installations.

as nothing new happens “on the wire” and nothing new is needed for displaying, there is no need that all UI implement things at the same time, so, eg. Android could just start with adding a selector once the API is done.

of course, UI can add more options to the sticker selector, eg. images from well-known folders can be added to other tabs; this is already working that way on desktop. iOS also has a working sticker-sending-alternative by the keyboard in the upcoming version (Memojis).
and, if one day, we decide to support sticker packs somehow in core, we can do that in addition :slight_smile:

5 Likes
2

I like the pragmatic approach to get things started and having a flexible approach. But in my opinion we should also support sticker packs at some point, either because one has them locally sorted like this (on desktop we sort them by the folder name) or because people just want to have them somehow organized. But also having single stickers is quite a nice thing.

2 Likes
3

Yeah extending it later by some sort of grouping would be nice.

But one thing: some users will find it irritating to have stickers in there that they don’t added/used themselves, so maybe only display them in recently seen at first and when there were used or “added” to the own collection they can be promoted to appear in the all tab? also an option to remove them from ones collection will be requested by users. (which should not delete the original message they appeared in.)

Also maybe later we could use some de-duplication, so sticker blobs aren’t duplicated inside of the db, that won’t reduce traffic usage, but can reduce the disk space taken by stickers.

2 Likes
4

I really like the approach that has been given so far

I think that, as a priority, the stickers provided by the keyboards should be allowed from now on, only this would already be a great advance.

I have also seen that there are some applications with sticker packages for WhatsApp, if it were possible in some standard way that Delta could accept them as such, I think it would also be another great advance.

2 Likes
5

I think that the stickers that are in the image editor could also be shown, on several occasions I have wanted to take them out of there to send them to someone. :sweat_smile:

6

indeed, sending system-provided-stickers as such on android would already be super-helpful! we just added that feature on iOS, tbh, i thought somehow, that was already existing on android :slight_smile: thanks for reminding! i filed an issue for that at #1945.

2 Likes
7

To re-ignite discussion on this, I have some ideas on this for myself

There are some real nice things about stickers in other platforms that would get lost with an approach like this, namely these stickers probably wouldn’t be indexable (as in, search-by-name) and they are hardly able to be shared in masses because of the whole “no packs” thing

Though, I figure a simple enough solution would be using existing metadata structures, i.e consisting of some basic metadata for a pack and each contained sticker, including:

  • Name of the Pack
  • Author / Credit / Attribution
  • Metadata for each sticker:
    • Sticker name (matching a-z A-Z _ 0-9)
    • Filename
    • Size (as in, image dimensions)
    • Associated emoji (array of emoji, can be used as a fallback for i.e notifications)

A lot of this data is already covered by existing formats, i.e Signal’s stickerpack format or Misskey (and co.)'s custom emoji format

One unique property of importable packs for Misskey is that they are effectively just zipfiles with both the images and metadata contained as PNGs (or GIFs, webp, etc) and a single meta.json file

We could very much use this existing format and build on-top of it

For example, we may want to make it possible to share stickerpacks, the simplest way is to make these share-able directly in chat (i.e like .xdc)

Though, to make this more like Signal, Telegram and co., we could include a stickerpack_url pointing to a HTTP(s) host with the stickerpack zip and a stickerpack_sha256 for the hash of the zip with every sticker sent that belongs to a pack, so that the receiving client can fetch the pack for themselves and then verify that it is indeed what was supposed to be downloaded. This could also be displayed in a “Received Stickers” section of the app where users can optionally add stickerpacks that they’re received.

To make hosting these easier, maybe packs could optionally be hosted on the chatmail server, probably encrypted to cut down on metadata (with the key then included at the end of the stickerpack download URL after a /#?); Though this could increase the cost of running a chatmail server and also opens up issues about chatmail servers being abused for storage.

2 Likes