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 <[email protected]> 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 <[email protected]> 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: [email protected] >> _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
