[Standards] Support for stickers (custom emojis)

Andrew Nenakhov andrew.nenakhov at redsolution.com
Thu Oct 17 15:26:25 UTC 2019

I think we have this covered. Here is what we assumed users want from
 - sticker most often  is an expanded graphical representation of some
 - one sticker can be associated with several different emotions (thus,
several emojis)
 - stickers come in packs
 - when a user receives a sticker from a pack he does not have downloaded,
he still must be able to display the image
 - he should also be able to download and use new sticker pack -> sent
stickers should contain information on where users can get them
 - stickers should have the same height-width requirements as in other
popular messengers, to ease porting them for use in XMPP

So we came up with the following solution: the body contains a fallback
link for legacy clients, sticker URI and sticker name.

<message from="juliet at capulet.it" to="romeo at montague.it" id="1">
    <reference xmlnx="urn:xmpp:reference:0" type="sticker" begin="0"

Since it is a sticker, receiving client knows that the root directory with
a sticker file SHOULD contain pack.xml file which describes all stickers in
a pack. https://stickers.xabber.com/monsters/pack.xml contains this:

<sticker-pack name="Monsters" version="1">
    <archive name="pack.zip" />
    <description>Funny monsters</description>
        <name>Andrey Nasayev</name>
        <company>redsolution OÜ</company>
        <email>andrey.nasayev at redsolution.com</email>
        <jid>andrey.nasayev at redsolution.com</jid>
        <sticker name="angry face">
            <file id="1">
            <description>Angry Face</description>
        <sticker name="bandaged head">
            <file id="1">
            <description>Face With Head-Bandage</description>

All links in this sample are live. We have tasked our designer to create
our own copyright-free set of stickers (and a couple more sets are coming),
they are published under CC-BY license:
[image: image.png]

Sample stickers:

Unsolved problems:
 - how to notify clients that a set is updated. Currently, we have versions
in pack.xml file, but if a client will not renew this data, it's all for
 - stickers with different DPI. Should we even need them? If yes, likely
apple approach would be easiest: we could store different versions of same
file using Apple's pattern: angry at 1x.webp, angry at 2x.webp, angry at 3x.webp.

General question regarding IP:
 - can we even use/host stickers that contain third party IP? Telegram, etc
has lots of Futurama / Disney / Movies stickers, they look to be an obvious
rights infringement. How do we work around that? Or is it a 'fair use'?

чт, 17 окт. 2019 г. в 15:10, JC Brand <lists at opkode.com>:

> Hello
> I'm currently working on adding support for non-unicode emojis to
> Converse.js.
> Currently, users can't upload their own images to be used for custom
> emojis,
> mostly because Converse is a thin client with no backend support for it.
> So to add custom emojis, the web host needs to edit a emojis.json file
> to add new entries with URLs pointing to the actual images.
> Concerning compatibility with other clients, I've discussed it with edhelas
> and he told me he uses XEP-0231 BOB for sending stickers.
> There are a few reasons why I'm not keen on using BOB:
> - BOB depends on XHTML-IM which is deprecated. Converse.js doesn't support
> it
>   and I'm reluctant to add support just for this.
> - BOB mentions that binary data should be smaller than 1KB. Not sure how
>   relevant that still is, but it discourages me from sending larger
> amounts.
> - The sending client needs to maintain a cache of all sent stickers.
> - AFAICT, when receiving an uncached BOB message via MAM and the sending
> client
>   is offline, then you can't get the image data.
> Instead, I propose that we use XEP-0372 references to indicate that a
> particular shortname (e.g. :dancingpanda:) should be replaced with an
> image.
> For example:
>     <message type="chat" from="them at chat.org" to="me at chat.org"
>         <body>I feel like dancing! :dancingpanda:</body>
>         <reference xmlnx="urn:xmpp:reference:0"
>                 begin="21"
>                 end="35"
>                 type="data"
>                 uri="https://images.com/dancingpanda"/>
>     </message>
> I'm not sure whether "type" should be "data", seems a bit too generic for
> me,
> perhaps it could be something else?
> Some criticisms of this approach from edhelas:
> - HTTP images can be sent to a webchat client served over HTTPS
> - There's no size limit, so users can send links to very large stickers
> Concerning the first criticism, a client can choose to not render HTTP
> images inline and instead make the shortname a link which opens the image
> in a
> new tab. Not ideal, but a compromise for the privacy and security
> conscious.
> For the second I don't have a good answer.
> That said, I currently still prefer my suggestion to using BOB. I'd be
> interested to hear your feedback and suggestions.
> Regards
> JC
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com <http://www.redsolution.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191017/5d084a34/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 350091 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191017/5d084a34/attachment-0001.png>

More information about the Standards mailing list