12 Dec
2025
12 Dec
'25
12:48 p.m.
This message constitutes notice of a Last Call for comments on
XEP-0377.
Title: Spam Reporting
Abstract:
This document specifies a mechanism by which users can report spam and
other abuse to a server operator or other spam service.
URL: https://xmpp.org/extensions/xep-0377.html
This Last Call begins today and shall end at the close of business on
2026-01-05.
Please consider the following questions during this Last Call and send
your feedback to the standards(a)xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
3. Do you plan to implement this specification in your code? If not,
why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?
Your feedback is appreciated!
12 Dec
12 Dec
2:54 p.m.
1. Is this specification needed to fill gaps in the
XMPP protocol
stack or to clarify an existing protocol?
Yes
2. Does the specification solve the problem stated in
the introduction
and requirements?
Yes
3. Do you plan to implement this specification in your
code? If not,
why not?
Yes. I have done in conjunction with blocking command at least.
4. Do you have any security concerns related to this
specification?
No
5. Is the specification accurate and clearly written?
Yes
24 Dec
24 Dec
12:11 p.m.
Hi,
1. Is this specification needed to fill gaps in the
XMPP protocol
stack or to clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction
and requirements?
Yes.
3. Do you plan to implement this specification in your
code? If not,
why not?
In Gajim we have implemented it.
4. Do you have any security concerns related to this
specification?
No.
5. Is the specification accurate and clearly written?
Yes.
Your feedback is appreciated!
The XEPs limits its own scope in the introduction to extending blocking command. But then
defines all report elements in a generic way and in the end just defines a section
"Use with the Blocking Command" which makes you believe its intended for
reporting to be used somewhere else in the future. Also the title of the XEP implies its a
general solution, when the introduction says the opposite.
If this tries to define base elements for reporting and blocking command is just an
example, the introduction should say that, so that we can judge the XEP in the last call
accurately for what it tries to be.
Further the disco feature is insufficient if this will be used as a base spec. The disco
feature should clearly state for which use case reporting is supported, in this case
Blocking Command.
So e.g. urn:xmpp:blocking:reporting:1
it should be a child of blocking, as it extends the blocking spec.
As such i would propose to move the section "Use with the Blocking Command" and
the disco feature to XEP-0191, and revert this XEP to a base XEP which defines just the
reporting elements.
There is nothing out there that defines how messages or users in a MUC can be reported,
and MUC is a considerable part of XMPP messaging. Its very likely that we want and need to
fill this gap soon. So i urge who ever needs to vote on these specs, to think 2 steps into
the future and guide authors so we have a coherent document landscape.
This does not mean that this spec needs to fill the gap for MUC, but it should not be
written oblivious to what we know we need soon. Instead it should lay the groundwork so
others can extend on it.
Regards
Philipp
2:58 p.m.
If this tries to define base elements for reporting and
blocking command is
just an example, the introduction should say that, so that we can judge the
XEP in the last call accurately for what it tries to be.
I agree with this. This XEPs purpose is to define a generic syntax for use
in all reporting contexts (and is already being used in contexts besides
what the XEP explicitly defines) and this should be clear to the reader.
Further the disco feature is insufficient if this will
be used as a base
spec. The disco feature should clearly state for which use case reporting
is supported, in this case Blocking Command.
So e.g. urn:xmpp:blocking:reporting:1
Hmm. I have no strong feeling here. Supporting both blocking and reporting
features would mean you support blocking with nested reporting. I believe
that is the current intent. Having an explicit blocking+reporting feature as
well could be fine I don't mind it but I don't know that we need it either.
As such i would propose to move the section "Use
with the Blocking Command"
and the disco feature to XEP-0191, and revert this XEP to a base XEP which
defines just the reporting elements.
It cannot go in 0191 as that is stable, and besides it is an extension to
0191 so doesn't belong there. It either belongs here or in yet another xep.
I think we have quite some tradition of the first XEP for a new syntax
also defining at least one way to use that syntax (otherwise the XEP by
itself is useless) and I support that formulation here.
There is nothing out there that defines how messages or
users in a MUC can
be reported, and MUC is a considerable part of XMPP messaging. Its very
likely that we want and need to fill this gap soon. So i urge who ever
needs to vote on these specs, to think 2 steps into the future and guide
authors so we have a coherent document landscape.
I think this XEP's syntax can directly support the MUC use case, but I agree
we will need another XEP that explicitly states that once an implementation
exists. I don't think it needs to be added here per se.
8:31 p.m.
Hi,
If you intend to support different contexts of blocking, then one would expect that the
context is mentioned in the feature. Or whats your idea for a feature name for the next
context, say MUC?
Further the
disco feature is insufficient if this will be used as a base
spec. The disco feature should clearly state for which use case reporting
is supported, in this case Blocking Command.
So e.g. urn:xmpp:blocking:reporting:1
Hmm. I have no strong feeling here. Supporting both blocking and reporting
features would mean you support blocking with nested reporting. I believe
that is the current intent. Having an explicit blocking+reporting feature as
well could be fine I don't mind it but I don't know that we need it either.
6 Jan
6 Jan
2:42 p.m.
On Wed, Dec 24, 2025 at 1:13 PM Philipp Hörist <philipp(a)hoerist.com> wrote:
The XEPs limits its own scope in the introduction to
extending blocking command. But then defines all report elements in a generic way and in
the end just defines a section "Use with the Blocking Command" which makes you
believe its intended for reporting to be used somewhere else in the future. Also the title
of the XEP implies its a general solution, when the introduction says the opposite.
If this tries to define base elements for reporting and blocking command is just an
example, the introduction should say that, so that we can judge the XEP in the last call
accurately for what it tries to be.
Further the disco feature is insufficient if this will be used as a base spec. The disco
feature should clearly state for which use case reporting is supported, in this case
Blocking Command.
I think there are 2, maybe 2.5 reads at this.
1) The spec is only meant to be used with the Blocking command. In
that case the section header "6. Use with Blocking command" is maybe
phrased a bit awkwardly, but should be an easy fix. I think the rest
of the XEP - even that part that reasons can be registered - is not in
opposition of that interpretation of the XEP.
2) The spec is meant as a generic reporting that can be used outside.
In that case the intro and other parts of the XEP need some (major?)
rewording. A pragmatic solution to the disco feature could for example
be that if blocking and reporting namespace are both announced then
they should be used together.
I think there is a variant of (2) in which further spam reporting
processing just 'forwards' the <report/> element defined in this XEP.
This means 377 remains in it’s use with the Blocking command. And any
forwarding to further centralized spam processing instances get their
own discovery and wrapper syntax on top of that. For clarity one could
maybe rename 0377 to "User Spam Reporting" or "User-triggered spam
reporting" (Not that, but you know what I mean). I think that a future
"Spam collection and centralized processing" XEP "borrowing" the
<report/> element from 377 is fine. Jingle Message Init for example
also borrows the <reason/> from Jingle. And SIMS borrows the <file/>
from jingle file transfer.
Semantically I think it makes sense that "XEP-xxxx: Spam collection
and centralized processing" says here is a <report/> we got from
"0377: User-triggered spam reporting" let’s do something with that.
But I must also admit that this is a more convenient approach that
would allow us to 377 through the process and worry about further spam
processing at a later stage.
cheers
Daniel
4:47 p.m.
Hi,
Here my suggestions again for the XEP
1. State clearly in the introduction that this XEP defines a generic element for re-use in
other, not yet defined, specs.
- This justifies the generic XEP title (which otherwise wouldnt, if this is *just* an
extension for blocking)
- It takes responsibility for the generic element re-use use case, this may be relevant
if there are changes requested in the future, which have nothing to do with the blocking
use case. As currently the author could rightfully refuse any changes that don't
affect the blocking command use case.
2. Clearly separate the second goal of the XEP, to define one such context where the
generic element is used.
- Clear separation helps to understand the intentions and that the XEP has two goals
3. Define a disco feature that mentions the context, e.g. urn:xmpp:blocking:reporting:1
- Because it is intended that the generic element is used in multiple other contexts,
the first use case should not claim the generic namespace urn:xmpp:reporting:1.
- Because this spec is also an extension of blocking, a natural candidate would be
urn:xmpp:blocking:reporting:1, which makes it clear that this functionality is depended on
the blocking spec.
Regards
Philipp
5:06 p.m.
3. Define a disco feature that mentions the context,
e.g.
urn:xmpp:blocking:reporting:1
- Because it is intended that the generic element is used in multiple
other contexts, the first use case should not claim the generic
namespace urn:xmpp:reporting:1.
I agree with everything except this. Why is it insufficient to say "if you
support both blocking and reporting then you support reporting in blocking" ?
5:10 p.m.
On Tue, 6 Jan 2026 at 16:48, Philipp Hörist <philipp(a)hoerist.com> wrote:
Hi,
Here my suggestions again for the XEP
1. State clearly in the introduction that this XEP defines a generic
element for re-use in other, not yet defined, specs.
- This justifies the generic XEP title (which otherwise wouldnt, if
this is *just* an extension for blocking)
- It takes responsibility for the generic element re-use use case, this
may be relevant if there are changes requested in the future, which have
nothing to do with the blocking use case. As currently the author could
rightfully refuse any changes that don't affect the blocking command use
case.
I generally agree with this. I thought it was clear from the outset, but on
a re-read I agree it suggests the syntax is only for this purpose in the
introduction, whereas the rest of the document separates the payload and
the blocking extension.
2. Clearly separate the second goal of the XEP, to
define one such context
where the generic element is used.
- Clear separation helps to understand the intentions and that the XEP
has two goals
Clarifying XEPs is always good.
3. Define a disco feature that mentions the context,
e.g.
urn:xmpp:blocking:reporting:1
- Because it is intended that the generic element is used in multiple
other contexts, the first use case should not claim the generic namespace
urn:xmpp:reporting:1.
- Because this spec is also an extension of blocking, a natural
candidate would be urn:xmpp:blocking:reporting:1, which makes it clear that
this functionality is depended on the blocking spec.
The feature is specific to reporting via blocking already. Section 3 begins:
Entities that support Service Discovery (XEP-0030) [2] and abuse reporting
using the blocking command as defined in this spec MUST respond to service
discovery requests with a feature of 'urn:xmpp:reporting:1'.
There's no behaviour associated with the report syntax except for blocking,
so it doesn't need another feature.
I would hesitate before suggesting that one XEP should add a "sub
namespace" to another's, I think that could get very confusing very fast.
If we had another consumer of reports, then we'd have another feature for
that mode of consumption (or production, I suppose).
Regards
Philipp
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
6 p.m.
Hi,
On Tue, Jan 6, 2026, at 18:10, Dave Cridland wrote:
The feature is specific to reporting via blocking
already. Section 3 begins:
Entities that support Service Discovery (XEP-0030) [2] and abuse reporting using the
blocking command as defined in this spec MUST respond to service discovery requests with a
feature of 'urn:xmpp:reporting:1'.
There's no behaviour associated with the report syntax except for blocking, so it
doesn't need another feature.
I would hesitate before suggesting that one XEP should add a "sub namespace" to
another's, I think that could get very confusing very fast.
If we had another consumer of reports, then we'd have another feature for that mode
of consumption (or production, I suppose).
Yes im aware that this generic namespace is specific for functionality with blocking
command now.
I think the text regarding that is clear enough in the XEP.
But i think its a missed chance to choose a namespace that semantically makes more sense.
Clearly separating the definition of the generic element, from the implementation in a
specific context.
On Tue, Jan 6, 2026, at 18:06, Stephen Paul Weber wrote:
I agree with everything except this. Why is it
insufficient to say "if you
support both blocking and reporting then you support reporting in blocking" ?
I wrote insufficient, when i believed it was intended that other future XEPs also are
supposed to announce urn:xmpp:reporting:1, but it seems the author is aware and it was
intended that no other XEP can announce this feature, because it is bound to blocking
command.
Regards
Philipp
7 Jan
7 Jan
7:04 a.m.
I agree with Philipp. The entire XEP is a bit confusing when it comes to the
question of scope: is it meant as a general mechanism to be used in multiple
places or rather tailored to the blocking command only?
In my opinion we should define a general reporting element usable in various
places and then define one (or two, see below) usage scenarios where this
element can be used in the same XEP as well (e.g. use with blocking command
etc.). Afaik that's what we usually do in other XEPs as well, isn't it?
I think some small rewording and restructuring should be enough to reach that
goal fairly easily.
Also: In Monal you can outcast a channel participant in the same dialog used
to moderate a message. It would be really cool to also report the user and
message as spam from the same dialog as well.
But since spam reporting is currently only defined for the blocking command,
that isn't possible, no?
I'm planning to implement that XEP in Monal as soon as reporting messages/
users in channels is somehow covered by the XEP. I had even already started
to implement it, when I realized that the reporting element isn't defined for
my channel moderation usecase at all.
-tmolitor
Am Dienstag, 6. Januar 2026, 19:00:42 CET schrieb Philipp Hörist:
Hi,
On Tue, Jan 6, 2026, at 18:10, Dave Cridland wrote:
The feature is specific to reporting via blocking
already. Section 3
begins: Entities that support Service Discovery (XEP-0030) [2] and abuse
reporting using the blocking command as defined in this spec MUST respond
to service discovery requests with a feature of 'urn:xmpp:reporting:1'.
There's no behaviour associated with the report syntax except for
blocking, so it doesn't need another feature.
I would hesitate before suggesting that one XEP should add a "sub
namespace" to another's, I think that could get very confusing very fast.
If we had another consumer of reports, then we'd have another feature for
that mode of consumption (or production, I suppose).
Yes im aware that this
generic namespace is specific for functionality with
blocking command now. I think the text regarding that is clear enough in
the XEP.
But i think its a missed chance to choose a namespace that semantically
makes more sense. Clearly separating the definition of the generic element,
from the implementation in a specific context.
On Tue, Jan 6, 2026, at 18:06, Stephen Paul Weber wrote:
I agree with everything except this. Why is it
insufficient to say "if you
support both blocking and reporting then you support reporting in
blocking" ?
I wrote insufficient, when i believed it was intended that other
future XEPs
also are supposed to announce urn:xmpp:reporting:1, but it seems the author
is aware and it was intended that no other XEP can announce this feature,
because it is bound to blocking command.
Regards
Philipp
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
14 Jan
14 Jan
2:27 p.m.
I'm planning to implement that XEP in Monal as soon
as reporting messages/
users in channels is somehow covered by the XEP. I had even already started
to implement it, when I realized that the reporting element isn't defined for
my channel moderation usecase at all.
You want moderators to use it to report to the server that the spam
originated from? Or you want participants to use it to report to mods of the
channel (ala "flag this message" buttons).
7 Jan
7 Jan
4:47 p.m.
On Tue, 6 Jan 2026 at 18:01, Philipp Hörist <philipp(a)hoerist.com> wrote:
Hi,
On Tue, Jan 6, 2026, at 18:10, Dave Cridland wrote:
Right, but simply supporting the reporting element "somewhere" isn't
a
feature that drives a behavioural change. So advertising it doesn't mean
clients can do something - you need to advertise a usage of it.
I understand that advertising a feature does serve the purpose of simply
advertising - that is, literally marketing - but the core feature of
feature advertising is feature negotiation, and that's perfectly
satisfied by the current XEP.
So all we could do - if we wanted - is to make it clearer *in the namespace
name* that this one is for reporting in blocking. But that's a breaking
change for something that's really just cosmetic.
The feature is specific to reporting via blocking
already. Section 3
begins:
Entities that support Service Discovery
(XEP-0030) [2] and abuse
reporting using the blocking command as defined in this
spec MUST respond
to service discovery requests with a feature of 'urn:xmpp:reporting:1'.
There's no behaviour associated with the report syntax except for
blocking, so
it doesn't need another feature.
I would hesitate before suggesting that one XEP should add a "sub
namespace" to another's, I think that could get very confusing very fast.
If we had another consumer of reports, then we'd have another feature
for that
mode of consumption (or production, I suppose).
Yes im aware that this generic namespace is specific for functionality
with blocking command now.
I think the text regarding that is clear enough in the XEP.
But i think its a missed chance to choose a namespace that semantically
makes more sense. Clearly separating the definition of the generic element,
from the implementation in a specific context.
On Tue, Jan 6, 2026, at 18:06, Stephen Paul Weber
wrote:
I agree with everything except this. Why is it
insufficient to say "if
you
support both blocking and reporting then you
support reporting in
blocking" ?
I wrote insufficient, when i believed it was intended that other future
XEPs also are supposed to announce urn:xmpp:reporting:1, but it seems the
author is aware and it was intended that no other XEP can announce this
feature, because it is bound to blocking command.
Regards
Philipp
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
6 Jan
6 Jan
8:38 p.m.
On Tue, Jan 6, 2026 at 5:48 PM Philipp Hörist <philipp(a)hoerist.com> wrote:
Hi,
Here my suggestions again for the XEP
1. State clearly in the introduction that this XEP defines a generic element for re-use
in other, not yet defined, specs.
- This justifies the generic XEP title (which otherwise wouldnt, if this is *just* an
extension for blocking)
- It takes responsibility for the generic element re-use use case, this may be
relevant if there are changes requested in the future, which have nothing to do with the
blocking use case. As currently the author could rightfully refuse any changes that
don't affect the blocking command use case.
2. Clearly separate the second goal of the XEP, to define one such context where the
generic element is used.
- Clear separation helps to understand the intentions and that the XEP has two goals
The XEP ties the reporting action to blocking and states a reason for
the why. I think this should remain that way.
The report itself, meaning the report element itself can implicitly be
used outside the XEP. Allowing this explicitly in the XEP is fine with
me.
cheers
Daniel
2:24 p.m.
On Fri, Dec 12, 2025 at 1:49 PM Daniel Gultsch <daniel(a)gultsch.de> wrote:
1. Is this specification needed to fill gaps in the
XMPP protocol
stack or to clarify an existing protocol?
Yes
2. Does the specification solve the problem stated in
the introduction
and requirements?
Yes
3. Do you plan to implement this specification in your
code? If not,
why not?
Yes. I've implemented the spec for Conversations a while ago.
4. Do you have any security concerns related to this
specification?
No
5. Is the specification accurate and clearly written?
Yes. I will however respond to something Philipp brought up in a separate email.
cheers
Daniel
13 Jan
13 Jan
2:27 p.m.
Hi,
Sorry with end-of year and all, I haven't had time to process this earlier.Le
vendredi 12 décembre 2025, 13:48:53 heure normale d’Europe centrale Daniel
Gultsch a écrit :
1. Is this specification needed to fill gaps in the
XMPP protocol
stack or to clarify an existing protocol?
yes
2. Does the specification solve the problem stated in
the introduction
and requirements?
yes
3. Do you plan to implement this specification in your
code? If not,
why not?
I plan to implement it.
4. Do you have any security concerns related to this
specification?
Not really security related, but I'm wondering if it should not be possible to
have several reasons, and so use an element instead of an attribute. A message
could be flagged as SPAM, PORN, and CSAM for instance (and we can imagine that
illegal material are treated with higher priority, so it's important to be
able to flag extensively).
I'm also worried that the "Servers MAY anonymize any submission to third-
party" if there is no mechanism to indicate if it's anonymized or not. IMHO,
it should either be a "MUST" or there should be a mechanism to indicate if
it's anonymized or not. I don't feel comfortable to let my user check a box to
report to original server if I can't be sure that it's anonymized.
5. Is the specification accurate and clearly written?
Mostly. I don't really get this sentence in §5:
```
Servers MUST NOT process a report if the report that do not explicitly include
the corresponding processing option.
```
Thanks for the work on this specification.
Best,
Goffi
1
days inactive
34
days old
15 comments
6 participants
participants (6)
-
Daniel Gultsch -
Dave Cridland -
Goffi -
Philipp Hörist -
Stephen Paul Weber -
Thilo Molitor