31 Mar
2026
31 Mar
'26
10:16 a.m.
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
31 Mar
31 Mar
10:20 a.m.
On 31 Mar 2026, at 11:16, Matthew Wild <mwild1(a)gmail.com> wrote:
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.
I think that’s not hard to solve (protocol-wise) with tombstoning in the archive, either.
The PR can be found at
https://github.com/xsf/xeps/pull/1514
LGTM.
/K
10:46 a.m.
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 -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
10:59 a.m.
On 31 Mar 2026, at 11:46, Marvin W. via Standards <standards(a)xmpp.org> wrote:
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
I think Matthew’s change is doing this the right way for Stable - Stable allows changes to
the XEP as long as they’re backwards/forwards compatible, which AFAICS Matthew’s proposal
is.
and probably
could even be advanced to Final by now
Yes, if the XEP was final, not making the change because of being Final would be a very
strong argument - but it’s not, and we should probably be following process for the state
the XEP is in, rather than the state it might later reach.
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).
True, and true.
I would propose to add time-based trimming as well.
Fair to want to expire by time, I think, although it’s only one query to get the desired
ID from the time.
/K
11:07 a.m.
Hi,
On Tue, 2026-03-31 at 11:59 +0100, Kevin Smith wrote:
I think Matthew’s change is doing this the right way
for Stable -
Stable allows changes to the XEP as long as they’re
backwards/forwards compatible, which AFAICS Matthew’s proposal is.
I don't disagree that it is formally correct and allowed to have this
change in a Stable XEP, but I believe the feature in of itself is more
of Experimental quality, meaning we might want to do changes to it that
are not backwards-compatible. If we introduce it into a Stable XEP, we
can't do that. I also fail to see the benefit of adding it to the
existing XEP over creating a new one.
After all, we intentionally have multiple XEPs and not one single
specification with a lot of optional parts. Denoting the status of
features within our specification set is one of the benefits we earn
from doing so. Let's make good use of it.
Marvin
11:08 a.m.
On 31 Mar 2026, at 12:07, Marvin W.
<xmpp(a)larma.de> wrote:
Hi,
On Tue, 2026-03-31 at 11:59 +0100, Kevin Smith wrote:
I think that’s fair.
/K
I think Matthew’s change is doing this the right
way for Stable -
Stable allows changes to the XEP as long as they’re
backwards/forwards compatible, which AFAICS Matthew’s proposal is.
I don't disagree that it is formally correct and allowed to have this
change in a Stable XEP, but I believe the feature in of itself is more
of Experimental quality, meaning we might want to do changes to it that
are not backwards-compatible.
11:20 a.m.
On Tue, 31 Mar 2026 at 12:09, Marvin W. via Standards
<standards(a)xmpp.org> wrote:
On Tue, 2026-03-31 at 11:59 +0100, Kevin Smith wrote:
I'm fine with this, if it's the consensus of the community/Council.
I agree we are far from "everything in one specification", but I think
there is a balance to strike between having every little feature in
individual XEPs, and having everything related to, say, archive
management, in one place. MUC is suffering from the effects of the
"small bolted on XEPs" approach right now, and it makes it a pain for
implementers to figure out what's what.
For me, this feature seemed small and backwards compatible, so it made
sense to include it in XEP-0313 because I feel like it fits. I agree
it would probably delay a transition to Final, but I don't see any
point in rushing that anyway (which is basically a dead-end state).
I'm just explaining my thought process - I don't feel strongly, and am
happy to submit it as a new XEP if everyone prefers that.
Regards,
Matthew
I think Matthew’s change is doing this the right
way for Stable -
Stable allows changes to the XEP as long as they’re
backwards/forwards compatible, which AFAICS Matthew’s proposal is.
I don't disagree that it is formally correct and allowed to have this
change in a Stable XEP, but I believe the feature in of itself is more
of Experimental quality, meaning we might want to do changes to it that
are not backwards-compatible. If we introduce it into a Stable XEP, we
can't do that. I also fail to see the benefit of adding it to the
existing XEP over creating a new one.
After all, we intentionally have multiple XEPs and not one single
specification with a lot of optional parts. Denoting the status of
features within our specification set is one of the benefits we earn
from doing so. Let's make good use of it.
11:28 a.m.
On 31 Mar 2026, at 12:20, Matthew Wild <mwild1(a)gmail.com> wrote:
On Tue, 31 Mar 2026 at 12:09, Marvin W. via Standards
<standards(a)xmpp.org> wrote:
I think this is also all fair.
A think we used to do, rarely, once upon a time, was having new specs as new documents,
and as they got (lowercase) stable rolled them into existing documents. I suppose that
would be an option here that would both address Marvin’s “we might need to change this
after publishing” and Matthew’s “Let’s not duplicate the MUC fragmentation”.
/K
On Tue, 2026-03-31 at 11:59 +0100, Kevin Smith
wrote:
I'm fine with this, if it's the consensus of the community/Council.
I agree we are far from "everything in one specification", but I think
there is a balance to strike between having every little feature in
individual XEPs, and having everything related to, say, archive
management, in one place. MUC is suffering from the effects of the
"small bolted on XEPs" approach right now, and it makes it a pain for
implementers to figure out what's what. I think Matthew’s change is doing this the right
way for Stable -
Stable allows changes to the XEP as long as they’re
backwards/forwards compatible, which AFAICS Matthew’s proposal is.
I don't disagree that it is formally correct and allowed to have this
change in a Stable XEP, but I believe the feature in of itself is more
of Experimental quality, meaning we might want to do changes to it that
are not backwards-compatible. If we introduce it into a Stable XEP, we
can't do that. I also fail to see the benefit of adding it to the
existing XEP over creating a new one.
After all, we intentionally have multiple XEPs and not one single
specification with a lot of optional parts. Denoting the status of
features within our specification set is one of the benefits we earn
from doing so. Let's make good use of it.
11:33 a.m.
On Tue, 31 Mar 2026 at 12:28, Kevin Smith <kevin.smith(a)isode.com> wrote:
On 31 Mar 2026, at 12:20, Matthew Wild <mwild1(a)gmail.com> wrote:
That does seem like a sensible compromise. Publish as a new XEP, but
with the option of rolling it into XEP-0313 before Final if we decide
(based on adoption, implementation/deployment experience) that it
passes the bar for that.
Regards,
Matthew
On Tue, 31 Mar 2026 at 12:09, Marvin W. via Standards
<standards(a)xmpp.org> wrote:
I think this is also all fair.
A think we used to do, rarely, once upon a time, was having new specs as new documents,
and as they got (lowercase) stable rolled them into existing documents. I suppose that
would be an option here that would both address Marvin’s “we might need to change this
after publishing” and Matthew’s “Let’s not duplicate the MUC fragmentation”. I don't disagree that it is formally correct
and allowed to have this
change in a Stable XEP, but I believe the feature in of itself is more
of Experimental quality, meaning we might want to do changes to it that
are not backwards-compatible. If we introduce it into a Stable XEP, we
can't do that. I also fail to see the benefit of adding it to the
existing XEP over creating a new one.
After all, we intentionally have multiple XEPs and not one single
specification with a lot of optional parts. Denoting the status of
features within our specification set is one of the benefits we earn
from doing so. Let's make good use of it.
I'm fine with this, if it's the consensus of the community/Council.
I agree we are far from "everything in one specification", but I think
there is a balance to strike between having every little feature in
individual XEPs, and having everything related to, say, archive
management, in one place. MUC is suffering from the effects of the
"small bolted on XEPs" approach right now, and it makes it a pain for
implementers to figure out what's what. 
1:18 p.m.
Hi Matthew,
Le mardi 31 mars 2026, 13:20:57 heure d’été d’Europe centrale Matthew Wild a
écrit :
On Tue, 31 Mar 2026 at 12:09, Marvin W. via Standards
<standards(a)xmpp.org> wrote:
[SNIP]
I agree we are far from "everything in one specification", but I think
there is a balance to strike between having every little feature in
individual XEPs, and having everything related to, say, archive
management, in one place. MUC is suffering from the effects of the
"small bolted on XEPs" approach right now, and it makes it a pain for
implementers to figure out what's what.
[SNIP]
Thanks for the feature proposal, it would be indeed a nice addition.
I do agree with Marvin and I think that it should go to a new XEP.
Please note that we have keywords that can now be specified in XEPs, you can
add a `MAM` one, and it will be easy to figure out which XEPs are related to
MAM. It's even better to have it in separated XEPs, as we then have metrics
such as the number of implementer, and we can easily find existing
implementations to test a new one.
Best,
Goffi
30
days inactive
30
days old
9 comments
4 participants
participants (4)
-
Goffi -
Kevin Smith -
Marvin W. -
Matthew Wild