LAST CALL: XEP-0377 (Spam Reporting)
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@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!
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
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
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.
Hi,
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.
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?
On Wed, Dec 24, 2025 at 1:13 PM Philipp Hörist <philipp@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
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
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" ?
On Tue, 6 Jan 2026 at 16:48, Philipp Hörist <philipp@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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
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
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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
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).
Hello everyone, Thank you for the feedback provided during the Last Call. I would like to respond and clarify my intent as a co-author of XEP-0377. Several comments suggest that the XEP could or should define a set of generic, reusable base elements for reporting, with the Blocking Command merely being one example use case. In contrast, the introduction of the XEP deliberately limits its scope to extending the Blocking Command, and this is intentional. To be explicit: I do not see the purpose of XEP-0377 as defining a generic reporting or abuse framework for XMPP. I see it as a pragmatic addition to the Blocking Command, and nothing more. If parts of the syntax later turn out to be reusable in other contexts, that is a welcome outcome, but an accidental one rather than a design goal. I fully agree that MUCs are a significant part of XMPP messaging. However, since XEP-0377 does not aim to be a generic solution to spam reporting or abuse handling, I consider MUC-related reporting out of scope here. To my knowledge, application of the Blocking Command itself is not a major or established concept in the context of MUCs, which further supports keeping this XEP narrowly focused. I also agree that there is a broader need for additional specifications in this space, and that the overall document landscape should be coherent and forward-looking. However, I do not believe that fulfilling that need depends on XEP-0377 becoming a generic base specification. My preference is to let this XEP progress as originally intended: a low-complexity, pragmatic extension point for reporting spam in the context of functionality that users already employ when reacting to spam, namely blocking the sender. My concern is that reworking XEP-0377 into a generic reporting base risks losing precisely those qualities: pragmatism and low complexity. I suspect that the lack of widely deployed generic spam-processing solutions in XMPP today is at least partly due to the complexity and ambition of such designs. Most of the Last Call feedback appears to focus on structure and clarity of scope, and is otherwise positive about the XEP's usefulness and adoption, with several indications of existing or planned implementations. Based on this, my intent is to improve the XEP so that it is clearer and better aligned with its intended goal, including a new title and other editorial changes, while accepting that this goal is less ambitious than some would prefer. One suggestion was to allow multiple reporting reasons (for example, SPAM, PORN, and CSAM) using an element instead of an attribute. I am leaving this out of scope for now, as supporting multiple reasons adds complexity, risks end-user confusion, and could lead to attempts to game the system. The XEP will remain simple and focused on the typical blocking use case. Another concern raised was about anonymization: "Servers MAY anonymize any submission to third-party services" and whether there should be a way to indicate if anonymization was applied. This has now been addressed in the XEP: the specification explicitly defines a single, acceptable anonymization method: removing the 'to' attribute from the reported message. This makes it immediately clear when anonymization has been applied, without requiring additional signaling, while still allowing servers the choice to anonymize or not. I have prepared for the changes in this pull request: https://github.com/xsf/xeps/pull/1506 My suggestion is that if, in the future, a new XEP emerges that defines a true base-level reporting framework, whether or not it builds on XEP-0377, we can then revisit XEP-0377 and evaluate whether it should defer to or integrate with that work. Until such a specification exists, I believe there is significant value in the current pragmatic approach and in allowing this XEP to advance in its present form. Kind regards, Guus On Wed, Jan 14, 2026 at 3:27 PM Stephen Paul Weber < singpolyma@singpolyma.net> wrote:
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). _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Tue, 6 Jan 2026 at 18:01, Philipp Hörist <philipp@hoerist.com> wrote:
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.
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.
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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Tue, Jan 6, 2026 at 5:48 PM Philipp Hörist <philipp@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
On Fri, Dec 12, 2025 at 1:49 PM Daniel Gultsch <daniel@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
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
participants (7)
-
Daniel Gultsch -
Dave Cridland -
Goffi -
Guus der Kinderen -
Philipp Hörist -
Stephen Paul Weber -
Thilo Molitor