[Standards] Support for stickers (custom emojis)
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,
- 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" />
<email>andrey.nasayev at redsolution.com</email>
<jid>andrey.nasayev at redsolution.com</jid>
<sticker name="angry face">
<sticker name="bandaged head">
<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:
- 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>:
> I'm currently working on adding support for non-unicode emojis to
> Currently, users can't upload their own images to be used for custom
> 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
> 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
> - The sending client needs to maintain a cache of all sent stickers.
> - AFAICT, when receiving an uncached BOB message via MAM and the sending
> 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
> 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"
> I'm not sure whether "type" should be "data", seems a bit too generic for
> 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
> 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.
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
CEO, redsolution, OÜ
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 350091 bytes
Desc: not available
More information about the Standards