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 > _______________________________________________
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
