[Standards] Support for stickers (custom emojis)

JC Brand lists at opkode.com
Thu Oct 17 12:41:24 UTC 2019


On Thu, Oct 17, 2019 at 03:05:32PM +0300, Sergey Ilinykh wrote:
>    Doesn't SIMS ([1]https://xmpp.org/extensions/xep-0385.html) resolve all
>    the concerns yet?

Yes, SIMS is more comprehensive than my example. It's still uses a XEP-0372
reference, so it's conceptually similar.

>    We can have a <source> with cid: uri too.

yep.

We could probably also specify under <sources> some JID which can return the BOB
data as Marvin suggested.

>    The only thing is missed as for me is an attribute where the referenced
>    text has to be removed or not.
>    Best Regards,

I'm not sure what you mean. The "begin" and "end" attributes on the
<reference> element can encapsulate the shortname of the sticker.

JC

>    Sergey
>    чт, 17 окт. 2019 г. в 14:24, Marvin W <[2]xmpp at larma.de>:
> 
>      Hi,
> 
>      Regarding your proposal:
>      - You should still add a hash in the reference somehow so that clients
>      *can* cache entries (even if you won't do it in Converse)
>      - I already dislike the fact that we do HTTP requests to arbitrary
>      servers for file transfers, as we might be leaking IP addresses in such
>      cases. In the case of Converse, you are likely to get into GDPR issues
>      when doing so without explicit user consent (and you don't want explicit
>      user consent for every emoji). There is a reason why many e-Mail-Clients
>      don't render remote content in e-Mails...
>      - When this is combined with body-only e2e-encryption, you are leaking
>      information as I guess you don't envision the emoji to be encrypted for
>      each e2e session individually.
> 
>      You can probably solve the second issue mentioned above and the issue
>      with http files by proxying the image request through the server hosting
>      Converse (which is what other popular sites that allow arbitrary http
>      links like GitHub do). But I guess you don't want to do that.
> 
>      Regarding your issues with using BOB:
>      - BOB does not depend on XHTML-IM. 0231 §2.2 specifically says that "any
>      appropriate format can be used" to share the CID. This means it is also
>      possible to use it in 0372 references (as you suggest to do just without
>      http).
>      - BOB does not require the sender to provide the file referenced by the
>      CID 0231 §2.1 says that you can send the IQ to request the bytes to
>      "potentially some other entity". If you don't expect the sending client
>      to provide the file, it doesn't need to cache all stickers and it
>      doesn't need to be online.
> 
>      Marvin
> 
>      On 10/17/19 12:07 PM, JC Brand wrote:
>      > Hello
>      >
>      > 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="[3]them at chat.org" to="[4]me at chat.org"
>      >          <body>I feel like dancing! :dancingpanda:</body>
>      >          <reference xmlnx="urn:xmpp:reference:0"
>      >                  begin="21"
>      >                  end="35"
>      >                  type="data"
>      >                  uri="[5]https://images.com/dancingpanda"/>
>      >      </message>
>      >
>      > 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.
>      >
>      > Regards
>      > JC
>      >
>      >
>      > _______________________________________________
>      > Standards mailing list
>      > Info: [6]https://mail.jabber.org/mailman/listinfo/standards
>      > Unsubscribe: [7]Standards-unsubscribe at xmpp.org
>      > _______________________________________________
>      >
>      _______________________________________________
>      Standards mailing list
>      Info: [8]https://mail.jabber.org/mailman/listinfo/standards
>      Unsubscribe: [9]Standards-unsubscribe at xmpp.org
>      _______________________________________________
> 
> References
> 
>    Visible links
>    1. https://xmpp.org/extensions/xep-0385.html
>    2. mailto:xmpp at larma.de
>    3. mailto:them at chat.org
>    4. mailto:me at chat.org
>    5. https://images.com/dancingpanda
>    6. https://mail.jabber.org/mailman/listinfo/standards
>    7. mailto:Standards-unsubscribe at xmpp.org
>    8. https://mail.jabber.org/mailman/listinfo/standards
>    9. mailto:Standards-unsubscribe at xmpp.org

> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191017/aea208a1/attachment-0001.sig>


More information about the Standards mailing list