Stickers XEP - Working out the details

[Gargron]

So, I would like to discuss the realities and intricansies of implementing stickers in XMPP. I've come up with a very simplicistic draft that assumes there's a central authority that hosts stickers and controls their availability and namespaces.

In a nutshell:

<message
    from="alice@example.com"
    to="bob@example.com"
    type="chat">
  <sticker xmlns="http://jabber.zeonfederated.com/protocol/stickers"
      uid="pusheen.halloween.pumpkin" />
</message>

Would be a sticker-message wherein the UID means the organization/artist "pusheen", sticker pack "halloween" and sticker identified by "pumpkin", and would get translated by the receiving client into a HTTP asset URL. (The reason I decided not to send URLs in the first place is to prevent displaying random received URLs that could be malicious and also allowing to change the hosting place of the stickers without breaking history)

Is this viable? Is this okay? Could other clients potentially adopt support for this?

Another question is of course who gets to manage and host the inventory of stickers.

If you're asking yourself - who needs stickers? For enterprise usage, I suppose nobody; although my chats with my boss often involve an exchange of cute stickers that makes the whole thing quite fun. It's no secret though that a lot of normal, not technically-arcane people are attracted to cute stickers. They are essentially the sole reason the messaging app LINE took off at all.

Feedback and discussion welcome.

[0chroma]

Looks like a pretty well thought out implementation... I think the benefit of having the stickers endpoint would also be that it makes implementing a picker much easier, since I'm assuming http://jabber.zeonfederated.com/protocol/stickers will list all the available stickers.

As for security/management of the inventory of stickers, it could be configurable. You could keep a whitelist of allowed inventory endpoints. Then if a user receives a sticker from an endpoint that isn't whitelisted, the client can ask the user if they want to allow the endpoint, or even add it to their collection of stickers.

Not sure if any of that made any sense, let me know if I should elaborate! :)

[Gargron]

@hflw Technically http://jabber.zeonfederated.com/protocol/stickers is just the XML namespace for the <sticker> tag, but what you're suggesting makes sense. So we add another inventory attribute to the tag which will be a URL to the stickers inventory in question. The client can then compare it to its own known/trusted inventories and either display the sticker or prompt the user to subscribe to the new inventory.

I'm leaning towards making the inventories JSON files, because it would be so much easier to use in JS, but I'm having doubts because most clients will 100% already use XML parsers but unlikely to also use JSON parsers.

[Gargron]

@iNPUTmice Sorry for tagging you in, but with these amendments, is there a chance that Conversations will support this? I understand that a sticker picker UI is probably too much trouble to implement but adding a message type that just displays an image without a bounding box, and a bit of code that parses <sticker> tags into image URLs shouldn't be too much trouble. I could try doing it myself, even, I just want to know if it has a chance of getting accepted!

[0chroma]

mhm true JSON is a much nicer format but it's probably best to use XML since any developer implementing this will already have an XML parser set up.

[keiyakins]

Why not do it the way pidgin does? https://developer.pidgin.im/ticket/5627

That method also supports custom emoticons (which is how the pidgin UI presents them) but the only practical difference is that stickers are traditionally a bit larger.

[subpub]

If this project is ever going to be resumed: may the XEP-0385 can be used. Movim uses bits of binary--XEP 0231 for its stickers

[badrihippo]

@uchchishta sounds like a good idea.

I assume it's the client that's going to be sending the stickers, right? So each client could have their own namespace for stickers, and if the receiving client doesn't have that sticker in its cache it can request it to be loaded from the sending client. Under the hood, it would basically be a normal file-transfer.

Of course, we could optimise this further by letting the server cache the stickers, once for each namespace, to avoid having to upload it multiple times.