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

Kevin Smith kevin.smith at isode.com
Mon Nov 27 17:43:05 UTC 2017


On 24 Nov 2017, at 08:23, Daniel Gultsch <daniel at gultsch.de> wrote:
> 
> 2017-11-23 23:45 GMT+01:00 Kevin Smith <kevin.smith at isode.com <mailto:kevin.smith at isode.com>>:
>> 
>>> 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.
> 
> 
> Yes. It absolutely has to be in 0313. If we decide to store what is
> basically useless (not having the real jid sender), incomplete garbage
> in the user archive we definitely need a way to not query it during
> catch up. And that method has to be specified in the XEP as a MUST. I
> don't want to gamble that every server out there will implement some
> niche third party XEP.

I don’t think this is true. We assume that servers implement those XEPs that are useful for their particular deployment needs. I think that specifying option (3) outside 313 would work fine, for example, and falls back gracefully to the default rules in 313 if we say they don’t return gc by default.

/K
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171127/46778f3b/attachment.html>


More information about the Standards mailing list