Re: [Standards] XEP-0313 for transports
On Mittwoch, 26. Februar 2020 16:40:06 CET Ivan Vučica wrote: > Hi, > > Sometimes, protocols backing transports may support querying for an > archive similar to how it's done with XEP-0313. > > tl;dr Can querying archives on non-own, non-MUC, non-pubsub JID for > 1:1 chats be standardized? Can it be standardized that server > implementations don't have to support date-based queries? > > > > 1. XEP-0313 is specified for archives maintained by the user's own > server. Section 3.3 doesn't specify that a client can query a remote > JID for the archive, which would be useful for transports. It does > specify it for MUC and pubsub, but not for 1:1. > > Here I'm mainly interested: Are there clients that would query a > remote JID for the archive today, despite XEP-0313 not requiring > servers nor clients to support this? Under which conditions would they > do this? Ugh. No, I don’t think any client would query a remote JID for 1:1 archives. They only do that for XEP-0045 group chat archives. I see where you’re coming from with the transport perspective, but this one is really tricky: the user’s server will *also* have archived the transport messages because they’re 1:1 (while user servers generally do not archive type='groupchat', unless for XEP-0369). The problem with this is that archive queries and merging archives isn’t easy or cheap. It takes I/O and network bandwidth and logic for merging and deduplicating the messages isn’t trivial either. So clients would generally want to avoid remote archives sources where possible, I guess. However, even though your local server has (the recent parts of) your transport history archived, s2s failures and other things (like the transport losing the session and requiring an active client / password entry to resume the session) may lead to loss which can only be recovered with active s2s-archive-syncing (which we don’t have). So this is a fun can of worms, which should probably *not* go into '313; While it can re-use the protocol from '313, the interaction of transport archives and the user server archives should be specified in a separate document. > 2. XEP-0313 is very adamant about filtering being defined based on > start date, end date and communication partner, and requires > server-side support for all three arguments. However, the very first > open(ish) protocol that I decided to check -- Telegram through its > library tdlib -- exposes an API that uses (message ID, offset, limit) > triplet when querying the archive. I’m not going to get into this and how much of an mis-use of RSM this is again now. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0313 for transports
On Mittwoch, 26. Februar 2020 16:40:06 CET Ivan Vučica wrote: > (Also, random thought: seeing XEP-0313 lapse into 'Deferred' is > concerning...) Actually, XEP-0313 is on the Council’s Short List for Last Call issuing (the step which leads to advancement to Draft). And as Paul says, indeed, Deferred just means that nobody has provided a substantial change to '313 in the past 12 months. Since we do not want to overwhelm the Community with too many LCs and CFEs going on at the same time, we only work through the short list rather slowly. The CFEs and LCs of the past few weeks all came from that list. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0313 for transports
> (Also, random thought: seeing XEP-0313 lapse into 'Deferred' is concerning...) The deferred state doesn't really have any meaning, only that there was no input on the XEP for over a year. Paul 26.02.2020 16:41:06 Ivan Vučica : > Hi, > > Sometimes, protocols backing transports may support querying for an > archive similar to how it's done with XEP-0313. > > tl;dr Can querying archives on non-own, non-MUC, non-pubsub JID for > 1:1 chats be standardized? Can it be standardized that server > implementations don't have to support date-based queries? > > > > 1. XEP-0313 is specified for archives maintained by the user's own > server. Section 3.3 doesn't specify that a client can query a remote > JID for the archive, which would be useful for transports. It does > specify it for MUC and pubsub, but not for 1:1. > > Here I'm mainly interested: Are there clients that would query a > remote JID for the archive today, despite XEP-0313 not requiring > servers nor clients to support this? Under which conditions would they > do this? > > 2. XEP-0313 is very adamant about filtering being defined based on > start date, end date and communication partner, and requires > server-side support for all three arguments. However, the very first > open(ish) protocol that I decided to check -- Telegram through its > library tdlib -- exposes an API that uses (message ID, offset, limit) > triplet when querying the archive. > > https://core.telegram.org/tdlib/docs/classtd_1_1td__api_1_1get_chat_history.html > > It seems like tdlib might already be supported if the clients didn't > specify start nor end, and only specified RSM set with > argument. > > I have not looked at what any other open(ish) protocol supports for > server-side archive retrieval, but I'd guess that either > timestamp+offset (0313 style) or messageid+offset (tdlib-style) will > be pretty standard. > > Some questions arise, though, particularly for client authors: > > - How ignorable are 'start' and 'end' on the server side? XEP defines > that support for them is required -- do the implementing clients > require 'start' and 'end' not to be ignored by the server? What would > happen if the server implementation ignored it and returned empty set? > - Do clients do something like recording the existence of 'archive > holes' based on time, and then use timestamps instead of IDs to fill > the local archive's holes from remote data? Would they do the wrong > thing if the response was a dummy message, + specifying > this message > - Would it make sense to have a revision of MAM which *requires* > clients are able to make requests *without* specifying the time? > Perhaps one that responds with some semantic information telling the > client 'I'm returning an empty set because I cannot query the archive > using a timestamp; please omit the time, but feel free to include a > message ID'? > > Does this fit in XEP-0313 or would new XEP be in order? > > (Also, random thought: seeing XEP-0313 lapse into 'Deferred' is concerning...) > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0313 for transports
Hi, Sometimes, protocols backing transports may support querying for an archive similar to how it's done with XEP-0313. tl;dr Can querying archives on non-own, non-MUC, non-pubsub JID for 1:1 chats be standardized? Can it be standardized that server implementations don't have to support date-based queries? 1. XEP-0313 is specified for archives maintained by the user's own server. Section 3.3 doesn't specify that a client can query a remote JID for the archive, which would be useful for transports. It does specify it for MUC and pubsub, but not for 1:1. Here I'm mainly interested: Are there clients that would query a remote JID for the archive today, despite XEP-0313 not requiring servers nor clients to support this? Under which conditions would they do this? 2. XEP-0313 is very adamant about filtering being defined based on start date, end date and communication partner, and requires server-side support for all three arguments. However, the very first open(ish) protocol that I decided to check -- Telegram through its library tdlib -- exposes an API that uses (message ID, offset, limit) triplet when querying the archive. https://core.telegram.org/tdlib/docs/classtd_1_1td__api_1_1get_chat_history.html It seems like tdlib might already be supported if the clients didn't specify start nor end, and only specified RSM set with argument. I have not looked at what any other open(ish) protocol supports for server-side archive retrieval, but I'd guess that either timestamp+offset (0313 style) or messageid+offset (tdlib-style) will be pretty standard. Some questions arise, though, particularly for client authors: - How ignorable are 'start' and 'end' on the server side? XEP defines that support for them is required -- do the implementing clients require 'start' and 'end' not to be ignored by the server? What would happen if the server implementation ignored it and returned empty set? - Do clients do something like recording the existence of 'archive holes' based on time, and then use timestamps instead of IDs to fill the local archive's holes from remote data? Would they do the wrong thing if the response was a dummy message, + specifying this message - Would it make sense to have a revision of MAM which *requires* clients are able to make requests *without* specifying the time? Perhaps one that responds with some semantic information telling the client 'I'm returning an empty set because I cannot query the archive using a timestamp; please omit the time, but feel free to include a message ID'? Does this fit in XEP-0313 or would new XEP be in order? (Also, random thought: seeing XEP-0313 lapse into 'Deferred' is concerning...) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Call for Experience: XEP-0198: Stream Management
пт, 21 февр. 2020 г. в 14:33, JC Brand : > I have worked on deployments where Converse.js is integrated together with > roster and presences and/or MUC presences and where pages are regularly > reloaded (i.e. not a single-page app). Btw, I assume you use a strophe.js library. Personally, I didn't dive into details, but my web developers who work with web version of Xabber, which also uses this library currenlty, complained to me about SM implementation there. It was something about it counting stanzas differently than ejabberd does. It was over a year ago so I am not very sharp on details, but I can ask them for a clarification, email me directly pls if you want it. > Is there anything specific about SM that you don't like? > > It's more lightweight than having to do MAM requests for all open chats as > well as making a new roster request every time your connection drops and it > also solves the problem of presences being dropped. Things I don't like in SM is that it was often marketed as a way to reliably control the message delivery in the past. Thankfully, now it's commonly accepted that it's not its goal. But currenlty I find this method of maintaining connection not viable for our most problematic platform, iOS. Thus, versioned methods of resuming chat state were born, and they're as applicable on desktops, as they are in web / iOS / Android devices. In worst-case scenarios, these methods result in equal amount of traffic as with SM on reconnection, in best cases they result in smaller amounts of traffic. Mind you, I'm not advocating to drop SM, it's just our position that it is redundant for us. -- 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] Call for Experience: XEP-0198: Stream Management
сб, 22 февр. 2020 г. в 14:49, Jonas Schäfer : > Instead of dropping SM and introducing explicit versioning protocols > everywhere, wouldn’t it make more sense to increase SM timeouts to something > useful for mobile clients? Versioned protocols have one more crucial advantage, that comes as a natural side-effect: if we go for the restoration of state instead of resuming the stream, we can cold-start a client way faster. You enter your credentials into a client, boom, in 3 seconds you see all your recent conversations, with marked unread messages, etc. Extremely useful on web clients. -- 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] Call for Experience: XEP-0198: Stream Management
To now overcrowd the discussion, I'll answer severals email in this one. пт, 21 февр. 2020 г. в 13:25, Daniel Gultsch : > Only someone who hasn't been on a German high speed train can say with > confidence that desktop and web clients don't need stream management. This clearly looks like a first world problem. There is no internet access in russian trains, at all. And, for that matter, there are no speed trains either, but one between Moscow and Saint-Petersburg. пт, 21 февр. 2020 г. в 13:37, Guus der Kinderen : > You've clearly never experienced my parent's WiFi. Sheesh just fix it! Buy them a decent router!!! They are like $30 now. Why do you let your parents suffer a horrible WiFi?! Jokes aside, I understand that sometimes desktops DO have bad internet access, but it's rather an exception, than a rule. Anyway, in our experience our approach works equally well (or better) than SM. пт, 21 февр. 2020 г. в 13:39, Martin : > Yes, mobile ≠ Android/iOS! Many notebook computers are connected > to Wifi or "mobile internet" and used in public transport, > (over-) crowded places, or rural areas with flaky connections. One of the problems of XMPP as a whole is their targeting only small subset of clients by some proposed extensions, and calling it a day, despite obvious problems on other clients in different environments. Proper approach is to target the most difficult plaftorm to work with (in our world, it's iOS), and spread up from there. Current SM is ... NOT really suitable for iOS. Thus, we're working out something else. If Stream Management works for you, well, I don't oppose you using it, but we seem to be on a better solution without it. Yes, our approach is harder on the server, but I firmly believe that in 2020 the heavy lifting shold be done by servers. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
