6 Jan
2026
6 Jan
'26
7:42 a.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