[Standards] XEP-0313: Treatment of type=groupchat in user archive with or without <store/> hint
mwild1 at gmail.com
Thu Nov 23 22:18:44 UTC 2017
On 23 November 2017 at 18:33, Daniel Gultsch <daniel at gultsch.de> wrote:
> 2017-11-23 18:33 GMT+01:00 Kevin Smith <kevin.smith at isode.com>:
>> The main use case for having gc messages in the archive is “I remember I saw someone say something interesting about X, so now I’m going to search my archive for X to find it”, which really needs to have all the messages you’ve seen available, rather than splitting them between multiple sources, some of which won’t support MAM.
>> I agree that for “catch-up”, it’s not particularly useful, but knowing exactly what messages you’ve seen is.
>> Perhaps filtering MAM queries on type would be sensible.
> OK. I buy the arguments with future proofing for MIX and 'backup'.
> However we really need a way to exclude type=groupchat from a normal catchup.
> I see three possibilities to achieve this.
> 1) Add a data form field 'exclude-groupchat' which can be set to '1'
> 2) Add a multi-item form field 'exclude-types'
> 3) Add a multi-item form field 'include-types'
> I think (2) is the best option here because it is more flexible than
> (1) and has a better default if absent behaviour then (3)
> If other people agree I can create a PR for that XEP.
Though I agree with your analysis, I don't particularly like any of
these approaches. It feels like a road towards a proliferation of
filters in the XEP, which is something I would really like to avoid.
I'd rather just not archive type=groupchat in the first place (which
is what current implementations are actually doing anyway). You are
perfectly right that the user archive server is 1) not the best place
to archive these messages and 2) not in the best position to make a
decision about whether they should be archived. Like you and Zash, I
was surprised at that text in the XEP.
What we have implemented and deployed today is already working, if we
can solve this issue with <store>. Let's update the XEP to match what
implementations are doing, which seems the simple and sensible
approach. We can additionally add text to clarify that this should
override the <store> hint, unless someone has another idea for solving
That leaves MIX, which through re-use of type='groupchat' already has
a problem. We should solve that separately.
More information about the Standards