[Standards] Proposed XMPP Extension: Stickers (use of PubSub)

Marvin W xmpp at larma.de
Thu Nov 19 14:43:16 UTC 2020


Hi,

On 19.11.20 15:03, Sam Whited wrote:
> IMO what this spec should do is ensure that there is a way to subscribe
> to notifications that a sticker pack has been updated, but not the
> actual sticker data (which can then be fetched later). I am not sure if
> pubsub gives us a way to do this on its own, or if you'd need to have
> two nodes to do this (one with hashes, one with actual data).
XEP-0060 allows to configure the node to be a notification-only node by
setting pubsub#deliver_payloads to false (§8.2). You can also list only
the item ids of items on a node (§5.5).

The XEP currently does not describe a way to subscribe to sticker pack
updates. Most notably, it's not advisable to use filtered notifications
(§9.2) as you are usually not interested in other users' sticker packs
(except if the user specifically asks for them). Item IDs are derived
from the content of the sticker pack, therefor once you know a sticker
pack, you don't need to fetch any item carrying its ID, allowing for
efficient caching of sticker packs.

I personally think that in most usecases, no subscriptions need to be
used at all. Clients can also check for updates (pull) when needed,
criteria could be
a) client sees in a message sent by another client of same user a
sticker referencing an unknown sticker pack
b) user opens the "send sticker" dialog in client and last update is
significant time ago
While pull is usually not preferable to push, the overhead of correctly
deploying the subscription model and uncertainties of implementation
behavior (last time I tried, anything but filtered notifications were a
mess in multi device scenarios) make the pull model more interesting in
this specific case. However, by using a pubsub node, clients are open to
still try and use subscription model, if it fits their usecase.

Marvin


More information about the Standards mailing list