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 <after/> 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, <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...) _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
