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

Sam Whited sam at samwhited.com
Thu Nov 19 14:03:36 UTC 2020


Thank you, that was much more helpful. Broadly speaking, I agree with
your whole message.

When I worked at HipChat we tried to figure out what needed to be
realtime and put that over the stream, and everything else goes over the
HTTP API whenever we had time for it or whenever the user actually
needed it depending on the situation. Our custom emoticon packs did not
use the main connection for this exact reason: even on desktops they
would have hogged the connection for far too long, and we didn't need
them to be instantly updated anyways.

It wouldn't be helpful for this specific spec (and every other spec that
might have this problem) to address the multi-connection scenario
individually. If this is something we want to solve, it seems worth
reusing XMPP standards like pubsub and IQs, and then exploring a
separate XEP for multi-stream clients so that clients can break down
requests over different streams however they want. This seems like a
very interesting line of work to me.

Back to stickers:

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).

It was never widely used here, but HipChat wrote XEP-0366: Entity
Versioning specifically to handle cases like this, I am not familiar
enough with the stickers XEP or pubsub yet to know if that would be
helpful here or not.

—Sam

On Thu, Nov 19, 2020, at 08:10, Andrew Nenakhov wrote:
> In mobile XMPP, especially on iOS, stream is an extremely valuable
> resource, because you have so little time to do so many tasks. Things
> are bad enough with presence flood, which chokes the stream every time
> on each new connect, so *anything* that excessively goes into the
> stream but actual messages is an obstacle.


More information about the Standards mailing list