[Standards] Support for stickers (custom emojis)
vanitasvitae at fsfe.org
Thu Oct 17 16:11:23 UTC 2019
I like that approach. Maybe we could fix the versioning by somehow adding the version to the sticker uri? Additionally clients could regularly check for updates of their "subscribed" packs.
Thu Oct 17 17:26:56 GMT+02:00 2019 Andrew Nenakhov <andrew.nenakhov at redsolution.com>:
> I think we have this covered. Here is what we assumed users want from stickers:
> - sticker most often is an expanded graphical representation of some emotion
> - 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 [mailto:juliet at capulet.it] " to=" romeo at montague.it [mailto:romeo at montague.it] " id="1">
> <body> https://capulet.it/monsters/zany.webp [https://capulet.it/monsters/zany.webp] </body> <reference xmlnx="urn:xmpp:reference:0" type="sticker" begin="0" end="35"> <uri>
> https://stickers.xabber.com/monsters/zany.webp [https://stickers.xabber.com/monsters/zany.webp] </uri> <name>smiling_face</name>
> 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 [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 [mailto:andrey.nasayev at redsolution.com] </email>
> <jid> andrey.nasayev at redsolution.com [mailto: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>
> </sticker> ...
> 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: [cid:ii_k1uuwpy50]
> Sample stickers: https://stickers.xabber.com/monsters/nerd.webp [https://stickers.xabber.com/monsters/nerd.webp] https://stickers.xabber.com/monsters/angry.webp [https://stickers.xabber.com/monsters/angry.webp] https://stickers.xabber.com/monsters/pouting.webp [https://stickers.xabber.com/monsters/pouting.webp] https://stickers.xabber.com/monsters/smiling.webp [https://stickers.xabber.com/monsters/smiling.webp] https://stickers.xabber.com/monsters/zany.webp [https://stickers.xabber.com/monsters/zany.webp]
> 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 nothing - 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 [mailto:lists at opkode.com] >:
>> 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 [mailto:them at chat.org] " to=" me at chat.org [mailto:me at chat.org] "
>> <body>I feel like dancing! :dancingpanda:</body>
>> <reference xmlnx="urn:xmpp:reference:0"
>> uri=" https://images.com/dancingpanda [https://images.com/dancingpanda] "/>
>> 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.
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards [https://mail.jabber.org/mailman/listinfo/standards]
>> Unsubscribe: Standards-unsubscribe at xmpp.org [mailto:Standards-unsubscribe at xmpp.org]
> Andrew Nenakhov
> CEO , redsolution, OÜ
> https://redsolution.com [http://www.redsolution.com]
-------------- 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