Re: [Standards] Proposed XMPP Extension: Stickers (use of PubSub)
Am Donnerstag, den 19.11.2020, 18:10 +0500 schrieb Andrew Nenakhov: > 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 > management unnecessary. > I think you are just reinventing matrix protocol. If xmpp is so non- usable on apple devices why bother making non-interoperable protocol (or client) when there's is already what you'll likely end up with. Just make a protocol gate to xmpp if you still want to support that. --rr ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Stickers (use of PubSub)
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 ___
Re: [Standards] Proposed XMPP Extension: Stickers (use of PubSub)
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. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Stickers (use of PubSub)
чт, 19 нояб. 2020 г. в 17:45, Florian Zeitz : > > 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 management unnecessary. 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 pubsub updates. 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 problem. 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. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Stickers (use of PubSub)
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. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
