[Standards] Proposed XMPP Extension: Stickers (use of PubSub)
andrew.nenakhov at redsolution.com
Thu Nov 19 13:10:48 UTC 2020
чт, 19 нояб. 2020 г. в 17:45, Florian Zeitz <florob at babelmonkeys.de>:
> Am 19.11.20 um 11:11 schrieb Andrew Nenakhov:
> > Because you are happily oblivious to problems of clients on some
> > platforms that have a very tiny window of operation before they have
> > to break connection.
> May I suggest that you explicitly spell out your concern instead of
> being hostile?
> As far as I can tell for sending/receiving stickers this XEP does not
> actually use PubSub but SFS/plain file downloads. There is also no need
> to subscribe to the PubSub node, so your comparison with presence seems
> out of place. The only interaction with PubSub is upon creating and
> importing a sticker pack, which amount to a single IQ set/get
> request/response pair each.
> I do BTW admit to personally being relatively oblivious to mobile
> concerns, but not happily so.
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. So of course, we use HTTP
for hosting sticker packs and stickers themselves, and any client on
any OS can *easily* import any image by their URIs. This way clients
do not need to use pubsub or anything, just use the links, super easy.
Also, this model makes updating the pack more easy.
Beyond that, we've actually come to understanding that single-connect
model is fundamentally broken and stands in the way of good, and have
rather successfully implemented multiple streams into clients. So
loading dreaded presences and new messages come in the main stream,
where you post presence, and loading an archive for specific
conversations happens in another. Fetching list of group chat members
happens in another, etc. On iOS (and on Android too, actually) it is
almost always faster to open a new stream and fetch only the required
data, than to load everything on the only stream. This makes
interfaces far more responsive, and, among other things, makes stream
In our further plans we plan to solve the problem of presence flood,
by replacing current presences with one 'super presence' for an
account, stoping presence propagation to contacts, and merging this
super presence with roster versioning. This way, on each new reconnect
the client will have to do the following:
- catch up with changes in the list of recent conversations using
quick sync protocol
- fetch differences in roster version since last reconnect
- start receiving messages. It won't be flooded with presences, or
So far, we have quick sync protocol done & working, it syncs
everything in a couple of seconds, complete with unread messages and
read marker info. But presence and pep traffic still remains a
All of this is rather far stray from 'regular xmpp', but we just don't
see how we can make a good communication product using 'xmpp
compliance suites 2021' on all target platforms.
CEO, redsolution, OÜ
More information about the Standards