Forums This specification describes how to implement XMPP-based discussion forums. 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). xxxx ProtoXEP Standards Track Standards Council XMPP Core XEP-0060 XEP-0472 forums Pubsub Pubsub Social Feed Forums Jérôme Poisson goffi@goffi.org goffi@jabber.fr https://www.goffi.org 0.0.1 2025-10-14 jp

First draft.

XMPP has offered more than instant messaging since its early days. It notably provides a powerful Publish-Subscribe (XEP-0060) XEP-0060: Publish-Subscribe <https://xmpp.org/extensions/xep-0060.html>. foundation, which serves as the basis for many features.

Blogging is one such feature, initially implemented through direct use of RFC 4287 RFC 4287: The Atom Syndication Format <http://tools.ietf.org/html/rfc4287>. in Pubsub items, then via Microblogging Over XMPP (XEP-0277) XEP-0277: Microblogging over XMPP <https://xmpp.org/extensions/xep-0277.html>., and more recently with PubSub Social Feed (XEP-0472) XEP-0472: PubSub Social Feed <https://xmpp.org/extensions/xep-0472.html>., 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) XEP-0472: PubSub Social Feed <https://xmpp.org/extensions/xep-0472.html>. 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) XEP-0472: PubSub Social Feed <https://xmpp.org/extensions/xep-0472.html>.: one for flat forums, and one for threaded forums. The payload of those items uses Atom (RFC 4287 RFC 4287: The Atom Syndication Format <http://tools.ietf.org/html/rfc4287>.) via PubSub Social Feed (XEP-0472) XEP-0472: PubSub Social Feed <https://xmpp.org/extensions/xep-0472.html>..

Forums can be optionally organized in hierarchy using Pubsub Node Relationships (XEP-0496)XEP-0496: Pubsub Node Relationships <https://xmpp.org/extensions/xep-0496.html>., allowing for better organisation and easier discovery.

Advanced features such as reactions are implemented using Pubsub Attachments (XEP-0470) XEP-0470: Pubsub Attachments <https://xmpp.org/extensions/xep-0470.html>. and end-to-end encrypted forums are possible via standard pubsub e2ee specifications such as OpenPGP for XMPP Pubsub (XEP-0473) XEP-0473: OpenPGP for XMPP Pubsub <https://xmpp.org/extensions/xep-0473.html>..

To organize the forums, a service can optionally have a hierarchy. This is done by using Pubsub Node Relationships (XEP-0496)XEP-0496: Pubsub Node Relationships <https://xmpp.org/extensions/xep-0496.html>., 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.

  • A root node MUST NOT have any parent and MUST have a pubsub#type set to 'urn:xmpp:forums:root:0'.
  • This node MUST NOT have any items.
  • If a service provides a single forum hierarchy without user-created hierarchies, it MUST use the well-known name 'urn:xmpp:forums:0' for its root node and MUST advertise the feature 'urn:xmpp:forums:0' in response to Service Discovery (XEP-0030) XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>. disco#info requests.
  • In other cases (e.g., a generic pubsub service where users can create new forum hierarchies), any node name may be used; root nodes are then found by checking the value of the 'pubsub#type' attribute.
  • Root nodes SHOULD have a pubsub#title set to explain what the forum hierarchy is about.

Category nodes organize forums and function as folders containing other categories or forums.

  • A category node MUST have a parent set to either a root node or another category node.
  • Category depth may be arbitrary, but it is recommended to keep it low to avoid confusion from excessive subcategories.
  • A category node MUST have a pubsub#type set to 'urn:xmpp:forums:category:0' and MUST NOT have any items.
  • Category node names MUST follow the 'urn:xmpp:forums:category:0:<UNIQUE ID>' scheme, where '<UNIQUE ID>' is an identifier that MUST be unique across the service.
  • A category node MUST have a pubsub#title set to a suitable label for the category, which will be displayed to end-users.

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) XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>. 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) XEP-0462: PubSub Type Filtering <https://xmpp.org/extensions/xep-0462.html>. can be used in the later case if the pubsub service supports it.

Forums are based on PubSub Social Feed (XEP-0472) XEP-0472: PubSub Social Feed <https://xmpp.org/extensions/xep-0472.html>.. 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.

  • Flat forums MUST set the 'pubsub#type' to "urn:xmpp:pubsub-social-feed:flat-forums:0".
  • All replies MUST be posted to the comments node of the root post.
  • A reply MAY reference another reply by using a <in-reply-to/> element as specified in XEP-0472 §4.4 Replying to a Post.

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.
  • Threaded forums MUST set the 'pubsub#type' to "urn:xmpp:pubsub-social-feed:threaded-forums:0".
  • All published replies MUST link to a comments node (which can be created in advance, or automatically if the pubsub service supports auto-create as specified in XEP-0060 §7.1.4 Automatic Node Creation).
  • All replies MUST be posted to the comments node of the items they are replying to.
  • The <in-reply-to/> element as specified in XEP-0472 §4.4 Replying to a Post MUST NOT be used.

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) XEP-0060: Publish-Subscribe <https://xmpp.org/extensions/xep-0060.html>. 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) XEP-0413: Order-By <https://xmpp.org/extensions/xep-0413.html>. 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)XEP-0496: Pubsub Node Relationships <https://xmpp.org/extensions/xep-0496.html>.), 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)XEP-0496: Pubsub Node Relationships <https://xmpp.org/extensions/xep-0496.html>.. Otherwise, the client can look directly for forums profiles as defined in Forums Profiles. In both cases, PubSub Type Filtering (XEP-0462) XEP-0462: PubSub Type Filtering <https://xmpp.org/extensions/xep-0462.html>. 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) XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>. information request:

]]> ... ... ]]>

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)XEP-0496: Pubsub Node Relationships <https://xmpp.org/extensions/xep-0496.html>..

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) XEP-0475: Pubsub Signing <https://xmpp.org/extensions/xep-0475.html>.), attacks such as excessive node or item creation, and so forth.

This document does not require interaction with the Internet Assigned Numbers Authority (IANA) 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/>..

TODO

TODO