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

I mean where the encapsulated text has to be somehow presented to the user
or fully replaced with the sticker as if it never was there.
I believe in some cases (not stickers) the text has to be preserved for
SIMS.

Best Regards,
Sergey


чт, 17 окт. 2019 г. в 15:43, JC Brand <li...@opkode.com>:

> 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]x...@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]t...@chat.org" to="[4]
> m...@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-unsubscr...@xmpp.org
> >      > _______________________________________________
> >      >
> >      _______________________________________________
> >      Standards mailing list
> >      Info: [8]https://mail.jabber.org/mailman/listinfo/standards
> >      Unsubscribe: [9]standards-unsubscr...@xmpp.org
> >      _______________________________________________
> >
> > References
> >
> >    Visible links
> >    1. https://xmpp.org/extensions/xep-0385.html
> >    2. mailto:x...@larma.de
> >    3. mailto:t...@chat.org
> >    4. mailto:m...@chat.org
> >    5. https://images.com/dancingpanda
> >    6. https://mail.jabber.org/mailman/listinfo/standards
> >    7. mailto:standards-unsubscr...@xmpp.org
> >    8. https://mail.jabber.org/mailman/listinfo/standards
> >    9. mailto:standards-unsubscr...@xmpp.org
>
> > _______________________________________________
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > _______________________________________________
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> _______________________________________________
>
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to