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 _______________________________________________
