[Standards] NEW: XEP-0449 (Stickers)

Dave Cridland dave at cridland.net
Wed Dec 16 18:07:10 UTC 2020

I would just like to say that use of the word "anatidaephobic" means this
debate is now, in my view, essentially won by Ivan (though some details may
need to be discussed further of course).

On Tue, 15 Dec 2020 at 02:18, Ivan Vučica <ivan at vucica.net> wrote:

> Hi Marvin,
> sorry for taking so long to respond. Responding only to parts where I
> have concerns (not where I understand the PoV, but just wish it were
> different).
> Did you also consider valid-alternative-emojis problem?
> On Tue, Nov 24, 2020 at 11:43 PM Marvin W <xmpp at larma.de> wrote:
> >
> > Hi,
> >
> > On 24.11.20 22:20, Ivan Vučica wrote:
> > > 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.
> >
> > I indeed haven't thought about to multiple file formats for a single
> > sticker and I think it's a good idea to add those. Though I personally
> > think that files with/without animation should not be considered
> > different file formats, but instead should be different stickers,
> > possibly even in different sticker packs (one animated and one static
> > sticker pack of the same kind).
> I think different representations of the same concept are good, and if
> the user does not wish to see animations, displaying just the first
> frame of an animation is often not a substitute.
> >
> > > - 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
> >
> > The idea here was that PEP nodes typically are not world-readable but
> > require presence subscription and as such are only readable by contacts.
> > Contacts tend to know which sticker packs you are using anyway and also
> > they are supposed to be able to fetch them from you after receiving them.
> Not all of my contacts should know all of the sticker packs I use :)
> For instance, I may particularly like a sticker pack featuring ducks.
> However, with my anatidaephobic friend, I do not want to conjure up
> the image of ducks watching them, so they are unaware I use this pack.
> (Feel free to imagine a less ridiculous example here.)
> Groupchats have the opposite problem: publishing a pack in a locked
> down PEP node might mean they cannot fetch the pack I am using, a
> common action taken on non-XMPP software.
> >
> > > - It may make sense for <pack/> to *also* be an external reference to
> > > an HTTP document
> >
> > Do you mean for referencing a website of the sticker pack (whatever that
> > would be) or for fetching the sticker pack instead of fetching it
> > through pubsub? Alternative methods to transport indeed could be
> > explored here and uploading a XML file with the <pack/> would be an
> > option, but I fail to see the significant advantage of such approach.
> I can't recall what I had in mind.
> Perhaps I was thinking of how URLs are global addresses representing
> documents, and thus having a way to fetch a pack via HTTP would be
> neat, and possibly a cross-protocol approach. It would also allow
> updates (which you've mentioned is not interesting).
> Let's ignore this.
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20201216/56aebbb1/attachment.html>

More information about the Standards mailing list