[Standards] XEP-0313 for transports
jonas at wielicki.name
Wed Feb 26 17:24:18 UTC 2020
On Mittwoch, 26. Februar 2020 16:40:06 CET Ivan Vučica wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards