[Standards] NEW: XEP-0449 (Stickers)
ivan at vucica.net
Tue Dec 15 02:16:55 UTC 2020
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
Did you also consider valid-alternative-emojis problem?
On Tue, Nov 24, 2020 at 11:43 PM Marvin W <xmpp at larma.de> wrote:
> 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.
More information about the Standards