Re: Extending XEP-0313 with trimming support

Hi,

I generally am in favor of adding this functionality to our ecosystem.

I don't think this belongs into XEP-0313. It's an entirely new feature,
arguably needing to pass the "Experimental" state of XEPs, including
passing through Last Call. XEP-0313 is already Stable and probably
could even be advanced to Final by now (if it wasn't for it depending
on XEP-0359 which itself is still Experimental). The XEP-0313
introduction and requirements also don't list that trimming is an
intended functionality of that specification. There is explicit note
that uploading of messages it out of scope for it, which is more a hint
of the opposite. I would thus suggest to create an entirely new XEP for
trimming, so the feature can go the usual XEP process.

The pull request lacks an XML schema for the new namespace and element
and thus formally can't be merged into a Stable XEP (with schema being
mandatory for stable XEPs according to XEP-0001).

I would propose to add time-based trimming as well. ID-based trimming,
while exact and not prone to time zone or other similar issues, makes
it mandatory to fetch the respective message first. I can very much
imagine usecases where trimming by time is desired and messages have
not been downloaded yet.

Marvin

On Tue, 2026-03-31 at 11:16 +0100, Matthew Wild wrote:
> Hi folks,
> 
> There are a few limitations with XEP-0313 which I've been hoping to
> address for a while, mostly around giving users more control and
> making it easier for operators to comply with various data protection
> requirements.
> 
> Users have control over most account data in XMPP. However archives
> are, generally, read-only.
> 
> In particular, user data should generally be deleted upon request.
> Currently such requests would have to be manually sent to the service
> operator, as there is no in-band method for this yet.
> 
> My proposal is to support an in-band 'trim' command, which allows
> removal of all archived messages, or up to (and including) a specific
> archived message, or deletion of the entire archive. The
> functionality
> is optional and discoverable, so shouldn't affect backwards
> compatibility.
> 
> This has some limitations. For example, it wouldn't allow selectively
> deleting all messages with a specific contact, which is occasionally
> requested. Such an operation would leave holes in the archive (which
> XEP-0313 forbids to ensure sync points don't get removed). But I'm in
> favour of solving what we easily can for now.
> 
> There are other things I would like to improve around archiving, such
> as exposing retention configuration. But I plan for these to live in
> new XEPs.
> 
> As XEP-0313 is stable and almost universally implemented, I wanted to
> raise awareness of this proposal and seek some consensus from the
> community before pushing it forward to Council.
> 
> The PR can be found at https://github.com/xsf/xeps/pull/1514
> 
> The new section is rendered at
> https://matthewwild.co.uk/uploads/xep-0313.html#trim
> 
> Regards,
> Matthew
> _______________________________________________
> Standards mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]