[Standards] NEW: XEP-0449 (Stickers)
ivan at vucica.net
Tue Nov 24 21:20:23 UTC 2020
Reading through and considering this from both a potential client dev
and a potential sticker pack perspective, I'm not sure defining packs
as 'lists of files' -- i.e. equating a single sticker to a single file
-- is optimal.
I like that the spec allows <suggest/>; this allows both a single
emoji / suggestion to offer multiple stickers, and each sticker to
appear for multiple emojis. This is pretty cool.
- there are multiple smiling face emojis, and some sticker packs may
be happy covering all of those with a single image (and explicitly
- combining-element emojis (with skintone modifiers etc) create
multiple emojis; different sticker packs may want to treat them
However it also seems to me like the current spec might be suboptimal
in case a sticker pack wants to provide PNG + animated GIF + any other
media format. For instance, I may provide an animated GIF thumbs up,
an animated PNG thumbs up, but also a specific static PNG in case
someone desires not to see animations. These are not three different
stickers; they're the same sticker. Therefore, providing three images
with the same thumbs-up desc would not do the trick.
As far as I can tell, if referencing *only* Telegram, the current spec
would be fine, as each sticker is a thumbnail, a single emoji and a
However, XMPP clients may want to get more flexibility and, unlike
Telegram, offer static versions as well.
There's also no way to specify a thumbnail version for a particular emoji.
<!-- file-sharing denotes a single representation (animation,
static, etc); serves to group a file element with sources element -->
<file>...</file><!-- 512x512 animated gif -->
<file>...</file><!-- static png 512x512 -->
<file>...</file><!-- static png 32x32 -->
<file>...</file><!-- 512x512 mp4, no transparency -->
<!-- only one skintone variation -- *this* particular sticker
pack includes different images for different skintones (but each
version also suggests tone-less version -->
Some other thoughts:
- I like that the spec allows for discoverability of sticker packs via
- I have privacy concerns about PEP: publishing a sticker pack in a
discoverable PEP node means PEP components might leak all packs
imported by a user
- There's no way to update a sticker pack once imported by a user
- It may make sense for <pack/> to *also* be an external reference to
an HTTP document
Although this is now done and good enough, might as well mention a
different design. When I was previously considering stickers (but
never wrote a XEP), I thought of them as follows:
- a pubsub node publishing a directory of sticker packs
- each item a reference to another pubsub node, possibly on a remote
- a pubsub node for a sticker pack
- each item an individual sticker
- each sticker containing one or more equivalents of the 0447
What does everyone think? (And, more importantly, what do the client
On Tue, Nov 24, 2020 at 8:31 PM Ivan Vučica <ivan at vucica.net> wrote:
> This refers to two XEPs in inbox that are 404ing:
> 2. XEP-xxxx: File metadata element <https://xmpp.org/extensions/inbox/file-metadata.html>.
> (apparently now XEP-0446)
> 4. XEP-xxxx: Stateless file sharing <https://xmpp.org/extensions/inbox/sfs.html>.
> (apparently now XEP-0447)
> I suppose the text just needs updating?
> On Tue, Nov 24, 2020 at 6:16 PM Jonas Schäfer <jonas at wielicki.name> wrote:
>> Version 0.1.0 of XEP-0449 (Stickers) has been released.
>> This specification provides a protocol to send stickers and to create
>> and share sticker packs.
>> Accepted by vote of Council on 2020-11-18. (XEP Editor (jsc))
>> URL: https://xmpp.org/extensions/xep-0449.html
>> Note: The information in the XEP list at https://xmpp.org/extensions/
>> is updated by a separate automated process and may be stale at the
>> time this email is sent. The XEP documents linked herein are up-to-
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: Standards-unsubscribe at xmpp.org
More information about the Standards