Re: LAST CALL: XEP-0377 (Spam Reporting)

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 -- [email protected]
> To unsubscribe send an email to [email protected]

_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEN0CchbhrMgfxs4ncSg9KP3bcW1sFAmleBWQACgkQSg9KP3bc
W1t0cAf/U/O7Zxkqfsu89Jb3waO9W5ggy9GbfN3IgicCVqyzuqHZkbub5u2O4HRG
RlCGqQIPt9sCyPKbfgR9SuEaBAcY5dvyRxFok2UjG5wuRXmUuUDEOFywkxzv3itm
BnNLOBAA5YjLz84kPG8q4KiTVSOgohbmL7lEe96pbbb7Jkqv5Q64dee/m/CMBx72
C2yK+GE3eSfAfLuzRliBPLow2+egAL37ei8T3G46bWIT84EM2IokB0NOj5CmtbYW
MFtJ2ix31hzdpOcpIJFCrMZh1tkOlxSEaDnvu2xDHADLSPLzwjdsE4IL21g5WSf4
+f1Cw/nDn3Qm3gUHcBaM98Cbp5fn8g==
=mQ0u
-----END PGP SIGNATURE-----