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