[Standards] XEP-0313 for transports

Jonas Schäfer 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:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200226/e5721493/attachment.sig>


More information about the Standards mailing list