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

Daniel Gultsch daniel at gultsch.de
Tue Nov 28 10:04:05 UTC 2017


I've been reading XEP-0313 again in an attempt to figure out how to
word what you are describing and I came across »it refers to what
would appear to have been stored in order to satisfy the query.«

Keeping this in mind my pull request [1] is exactly what you want it to be.


(Plus or minus the reference to the <store/> hint which I already
offered to remove)

[1]: https://github.com/xsf/xeps/pull/547

2017-11-27 18:43 GMT+01:00 Kevin Smith <kevin.smith at isode.com>:
> 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>:
>
>
> 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
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>


More information about the Standards mailing list