[Standards] XEP-0313: Treatment of type=groupchat in user archive with or without <store/> hint

Kevin Smith kevin.smith at isode.com
Thu Nov 23 22:45:25 UTC 2017

> On 23 Nov 2017, at 22:18, Matthew Wild <mwild1 at gmail.com> wrote:
> 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.

There’s really no reason it has to be in 313, though, same as search doesn’t have to be.

> 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.

I disagree with both of these, though, for the reasons outlined earlier.

> 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>.

Except that it really shouldn’t be up to a remote entity what gets stored in my archive.

> Let's update the XEP to match what
> implementations are doing, which seems the simple and sensible
> approach.

Careful… :)


More information about the Standards mailing list