XMPP has offered more than instant messaging since its early days. It notably provides a powerful Publish-Subscribe (XEP-0060) [1] foundation, which serves as the basis for many features.
Blogging is one such feature, initially implemented through direct use of RFC 4287 [2] in Pubsub items, then via Microblogging Over XMPP (XEP-0277) [3], and more recently with PubSub Social Feed (XEP-0472) [4], a more generic basis for Atom-based features.
While blogging is ideal for one-to-many communication, it’s not well-adapted to multi-party, topic-specific discussions. Forums have therefore been used in various forms since the early days of the Internet – from Usenet and mailing lists to web-based platforms.
This specification describes how to implement forums with XMPP in a flexible way, allowing for feature-rich forums and the building of gateways to existing ones.
The design goals of this XEP are:
A forum is based on a node using one of the two dedicated PubSub Social Feed (XEP-0472) [4] profiles. This node items are the forum topics. Each topic has a comments node where replies can be posted.
This specification describes two forum profiles for PubSub Social Feed (XEP-0472) [4]: one for flat forums, and one for threaded forums. The payload of those items uses Atom (RFC 4287 [2]) via PubSub Social Feed (XEP-0472) [4].
Forums can be optionally organized in hierarchy using Pubsub Node Relationships (XEP-0496) [6], allowing for better organisation and easier discovery.
Advanced features such as reactions are implemented using Pubsub Attachments (XEP-0470) [5] and end-to-end encrypted forums are possible via standard pubsub e2ee specifications such as OpenPGP for XMPP Pubsub (XEP-0473) [7].
To organize the forums, a service can optionally have a hierarchy. This is done by using Pubsub Node Relationships (XEP-0496) [6], which defines the 'parent' relationship used in this specification. The pubsub#type and pubsub#title refer to the configuration fields of a pubsub node as described at XEP-0060 §8.2.
Two types of nodes are used for the hierarchy: root nodes and category nodes.
Root nodes serve as the entry point for forums.
Category nodes organize forums and function as folders containing other categories or forums.
A client can find forum hierarchies by either checking the well-known node (if the service announces the feature 'urn:xmpp:forums:0' in response to Service Discovery (XEP-0030) [8] disco#info requests) or by looking for nodes with the 'pubsub#type' attribute set to 'urn:xmpp:forums:root:0'. PubSub Type Filtering (XEP-0462) [9] can be used in the later case if the pubsub service supports it.
Forums are based on PubSub Social Feed (XEP-0472) [4]. Two profiles are defined: one for flat forums and one for threaded forums. In both cases, a forum consists of a forum node in which each item consists of a root post. Each root post MUST:
The organization of replies depends on the forum type.
With this profile, the XMPP client knows that the view is flat, and can detect the links between replies with the <in-reply-to/> element, and show them with whatever user interface is appropriate.
With this profile, the XMPP client knows that the view is a tree-like view of nested threads.
In forums, publications can often be edited, and with Publish-Subscribe (XEP-0060) [1] alone, this will overwrite the old item with a new one, causing it to appear before items published later. However, for forums we often want chronological order; this can be achieved by using Order-By (XEP-0413) [10] to order by date of creation.
Forums (i.e., the nodes with one of the two profiles defined in Forums Profiles) can have no parent (mostly used in pubsub services which do not support Pubsub Node Relationships (XEP-0496) [6]), have a category node as parent, or have a root node as parent. They can also be siblings to category nodes (i.e., have the same parent as a category node) if it makes sense for them to appear at the same level as some categories.
Root posts must include both a <title> and a <content> element. Replies may include both a <title> and a <content> (where the <title> serves as the reply's title), or only a <title> (which will be used as the body, resulting in a reply without a distinct title). The XMPP client determines whether to require a title for replies.
Forums can be created on a generic pubsub service, in which case no forums-specific discovery feature is advertised. A client can discover a forum by looking for root nodes (i.e., nodes with the type "urn:xmpp:forums:root:0") if the server supports Pubsub Node Relationships (XEP-0496) [6]. Otherwise, the client can look directly for forums profiles as defined in Forums Profiles. In both cases, PubSub Type Filtering (XEP-0462) [9] can be used to make discovery easier, if the pubsub service supports it.
If a service has a built-in forums support (e.g., a gateway to an existing forum), it MUST advertise it by including the "urn:xmpp:forums:0" discovery feature in response to a Service Discovery (XEP-0030) [8] information request:
<iq type='get'
from='juliet@example.org/balcony'
to='forums.example.org'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
<iq type='result'
from='forums.example.org'
to='juliet@example.org/balcony'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='urn:xmpp:forums:0'/>
...
</query>
</iq>In this case the service MUST have a root node with the well-known name "urn:xmpp:forums:0" and MUST implement Pubsub Node Relationships (XEP-0496) [6].
There are many inherent risks in using forums, primarily depending on their public visibility and popularity. Forum services should implement robust moderation tools and monitor content for spam, aggressive behavior, inappropriate content, bullying, sexism, racism, and other toxic behavior.
General security considerations related to PubSub services apply, notably impersonation risks (which can be mitigated by services supporting the 'publisher' attribute and the use of Pubsub Signing (XEP-0475) [11]), attacks such as excessive node or item creation, and so forth.
This document does not require interaction with the Internet Assigned Numbers Authority (IANA) [12].
TODO
TODO
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-0060: Publish-Subscribe <https://xmpp.org/extensions/xep-0060.html>.
2. RFC 4287: The Atom Syndication Format <http://tools.ietf.org/html/rfc4287>.
3. XEP-0277: Microblogging over XMPP <https://xmpp.org/extensions/xep-0277.html>.
4. XEP-0472: PubSub Social Feed <https://xmpp.org/extensions/xep-0472.html>.
5. XEP-0470: Pubsub Attachments <https://xmpp.org/extensions/xep-0470.html>.
6. XEP-0496: Pubsub Node Relationships <https://xmpp.org/extensions/xep-0496.html>.
7. XEP-0473: OpenPGP for XMPP Pubsub <https://xmpp.org/extensions/xep-0473.html>.
8. XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>.
9. XEP-0462: PubSub Type Filtering <https://xmpp.org/extensions/xep-0462.html>.
10. XEP-0413: Order-By <https://xmpp.org/extensions/xep-0413.html>.
11. XEP-0475: Pubsub Signing <https://xmpp.org/extensions/xep-0475.html>.
12. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/
First draft.
@report{poisson2025forums,
title = {Forums},
author = {Poisson, Jérôme},
type = {XEP},
number = {xxxx},
version = {0.0.1},
institution = {XMPP Standards Foundation},
url = {https://xmpp.org/extensions/xep-xxxx.html},
date = {2025-10-14/2025-10-14},
}END