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?

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

On Tue, 6 Jan 2026 at 16:48, Philipp Hörist <philipp(a)hoerist.com> wrote: 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. Clarifying XEPs is always good. 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).

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:

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(a)singpolyma.net&gt; wrote:

On Tue, Jan 6, 2026 at 5:48 PM Philipp Hörist &lt;philipp(a)hoerist.com&gt; wrote: 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