[Standards] XEP-0313 for transports

Ivan Vučica ivan at vucica.net
Wed Feb 26 15:40:06 UTC 2020


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.


It seems like tdlib might already be supported if the clients didn't
specify start nor end, and only specified RSM set with <after/>

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, <first>+<last> 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...)

More information about the Standards mailing list