[Standards] NEW: XEP-0449 (Stickers)

Ivan Vučica 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.

For instance:
- there are multiple smiling face emojis, and some sticker packs may
be happy covering all of those with a single image (and explicitly
state so).
- combining-element emojis (with skintone modifiers etc) create
multiple emojis; different sticker packs may want to treat them
differently

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
file: https://core.telegram.org/tdlib/docs/classtd_1_1td__api_1_1sticker.html

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.

How about:

<pack xmlns="...">
  <name>...</name>
  <item>
    <sticker>
      <file-sharing xmlns="urn:xmpp:sfs:0">
        <!-- file-sharing denotes a single representation (animation,
static, etc); serves to group a file element with sources element -->
        <file>...</file><!-- 512x512 animated gif -->
        <sources>...</sources>
      </file-sharing>
      <file-sharing xmlns="urn:xmpp:sfs:0">
        <file>...</file><!-- static png 512x512 -->
        <sources>...</sources>
      </file-sharing>
      <file-sharing xmlns="urn:xmpp:sfs:0">
        <file>...</file><!-- static png 32x32 -->
        <sources>...</sources>
      </file-sharing>
      <file-sharing xmlns="urn:xmpp:sfs:0">
        <file>...</file><!-- 512x512 mp4, no transparency  -->
        <sources>...</sources>
      </file-sharing>
      <suggest>+1</suggest>
      <suggest>👍</suggest>
      <suggest>👍🏿</suggest>
      <!-- only one skintone variation -- *this* particular sticker
pack includes different images for different skintones (but each
version also suggests tone-less version -->
      <suggest>💯</suggest>
      <suggest>:plusone:</suggest>
      <suggest>:thumbsup:</suggest>
    </sticker>
</pack>

Some other thoughts:

- I like that the spec allows for discoverability of sticker packs via
public nodes.
- 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
XMPP service
- a pubsub node for a sticker pack
  - each item an individual sticker
  - each sticker containing one or more equivalents of the 0447
<file-sharing/> element

What does everyone think? (And, more importantly, what do the client
authors think?)


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.
>>
>> Abstract:
>> This specification provides a protocol to send stickers and to create
>> and share sticker packs.
>>
>> Changelog:
>> 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-
>> date.
>> _______________________________________________
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: Standards-unsubscribe at xmpp.org
>> _______________________________________________


More information about the Standards mailing list