Abuse and spam are common issues on any open network. XMPP is no exception, and we have a range of protocols and tools to tackle various aspects of the problem. Until now, however, there has been no standard in-band way to report abuse in group chats.
This specification describes a protocol to report messages as abuse/spam, report problematic participants to group chat admins, and to report problematic group chats to server admins.
The requirements this specification aims to meet include:
The specification aims to reuse existing protocol containers which fit the data being transported. For example, it uses the report syntax from Blocking Command Reports (XEP-0377) [1].
The protocol is designed to work within the context of Multi-User Chat (XEP-0045) [2] or any group chat protocol that uses Anonymous unique occupant identifiers for MUCs (XEP-0421) [3] to identify occupants and uses JIDs to identify group chats.
<message to="chat@rooms.example.com" from="chat@rooms.example.com/spammer" type="groupchat">
<body>Click here to win $$$$: https://malware.example/buy-now</body>
<stanza-id id="019d29fc-bbcb-7920-93c2-64053721aa7b" by="chat@rooms.example.com" xmlns='urn:xmpp:sid:0'/>
</message>A participant in the chat reports this message, e.g. so it can be moderated using Message Moderation (XEP-0425) [4] and the sender banned.
<iq type="set" to="chat@rooms.example.com" id="report1">
<report-participant xmlns='urn:xmpp:gcreport:0'>
<occupant-id xmlns="urn:xmpp:occupant-id:0" id="dd72603deec90a38ba552f7c68cbcc61bca202cd" />
<report xmlns='urn:xmpp:reporting:1' reason='urn:xmpp:reporting:spam'>
<stanza-id id="019d29fc-bbcb-7920-93c2-64053721aa7b" by="chat@rooms.example.com" xmlns='urn:xmpp:sid:0'/>
<text xml:lang='en'>Malware distribution</text>
</report>
</report-participant>
</iq>Reporting happens via an <iq/> of type 'set' containing a <submit/> payload element qualified by the 'urn:xmpp:gcreport:0' namespace.
The <submit/> element MUST contain one <occupant-id/> (defined in XEP-0421) which identifies the participant being reported.
It MUST also contain a single <report/> element, as defined by XEP-0377.
Per the rules of XEP-0377, the <stanza-id/> element is not required, but SHOULD be included if the reporter is reporting a specific message. This can help provide additional context to the recipients of the report, which helps improve incident resolution times. When provided, the referenced stanza MUST be a stanza sent by the reported participant, otherwise the server SHOULD ignore it.
In some cases, a user may want to report an entire group chat to the server operator. For example, if the chat, its subject or administrators violate the server’s policies.
<iq type='set' to='rooms.example.com' id='report1'>
<report-chat xmlns='urn:xmpp:gcreport:0'>
<jid>chat@rooms.example.com</jid>
<report xmlns='urn:xmpp:reporting:1' reason='urn:xmpp:reporting:abuse'>
<text xml:lang='en'>This channel violates the server's policy</text>
</report>
</report-chat>
</iq>Reports about a group chat are sent via an <iq/> of type 'set' to the MUC service JID. The payload of the stanza MUST be a <report-chat/> element qualified by the 'urn:xmpp:gcreport:0' namespace.
Within this element MUST be a single <jid/> element (also in the 'urn:xmpp:gcreport:0' namespace).
Finally, a single <report/> element (as defined in XEP-0377) MUST be included, specifying the reason for the report and any supporting evidence.
Group chats which support reporting participants and services which support reporting chats MUST both advertise the 'urn:xmpp:gcreport:0' feature in their XEP-0030 service discovery features.
Upon receipt of a report, a service SHOULD perform an appropriate action, such as immediately notifying appropriate people in an appropriate manner, and/or automatically moderating reported messages or hiding groups from public listings. Any automated actions MUST be reversible upon review,to minimise the consequences of malicious reports.
For reports about participants, JIDs with an affiliation of 'owner' or 'admin' are generally the appropriate recipients of any report notifications.
For reports about chats, the responsible entity is usually the server administrator
However, this XEP does not mandate any specific actions as the appropriate action may depend on context such as the nature of the deployment, the reporter and the reported entity.
No special accessibility concerns have been identified.
None.
Implementations MUST consider various attack vectors in reporting systems built upon this protocol. This includes:
These issues can typically be tackled using standard techniques such as rate limiting, and trust-based approaches based on the reporter (for example, reports from long-standing affiliated members may take priority over reports from new/untrusted users).
When processing reports, servers MUST consider the privacy of the reporter. Appropriate measures would include anonymization (including at least removal of the reporter’s JID) before forwarding the report to any third parties (such as a server where the abuse originated). If abuse originates from a remote server (e.g. a reported user hosts their account there), it cannot be assumed that the remote server can necessarily be trusted.
Likewise, the privacy of reported entities MUST also be considered - not least because false and malicious reports are entirely possible within this protocol. Servers MUST NOT cause any private data to be exposed to untrusted entities in response to a report.
None.
None.
This document aims to fill a gap in spam/abuse reporting, which already works well for direct (one-to-one) chats. It reuses existing protocols which have already been widely implemented and deployed.
TBD.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
1. XEP-0377: Spam Reporting <https://xmpp.org/extensions/xep-0377.html>.
2. XEP-0045: Multi-User Chat <https://xmpp.org/extensions/xep-0045.html>.
3. XEP-0421: Anonymous unique occupant identifiers for MUCs <https://xmpp.org/extensions/xep-0421.html>.
4. XEP-0425: Message Moderation <https://xmpp.org/extensions/xep-0425.html>.
Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/
@report{wild2026gcreport,
title = {Group Chat Reporting},
author = {Wild, Matthew},
type = {XEP},
number = {xxxx},
version = {0.0.1},
institution = {XMPP Standards Foundation},
url = {https://xmpp.org/extensions/xep-xxxx.html},
date = {2026-03-31/2026-03-31},
}END