XEP-0503: Server-side spaces

1. Introduction¶

A single group chat room is not always enough.

In various situations, one wishes to have several rooms (or even other entities) clustered together around a common theme. For instance, large open source software projects use different rooms for user support, development, announcements (examples: Slack's workspaces, Discord's servers, Mattermost's teams, WhatsApp's communities, Matrix's spaces). For the purpose of this document, let us call such group of entities under the umbrella term "spaces".

This clustering is already possible by setting up a dedicated MUC Service (Multi-User Chat (XEP-0045) [1]) to group several rooms, but existing implementations of MUC service leave that option the administrators only. This specification proposes to use the semantics of Publish-Subscribe (XEP-0060) [2] for spaces that:

• are groupchat protocol-independent;
• allow other types of entities than rooms (such as pubsub nodes);
• allow several spaces on a single pubsub service;
• allow entities to subscribe to updates of the space content;
• can be managed by users and not only administrators of a service.

Since there are many subtle variations over the concept of spaces, this specification voluntarily does not cover access control, permissions, membership inside a space and its children entities. Similarly, it does not describe how a space holding entities hosted on several services in the federated XMPP network would work (but it does not forbid it). It aims at being a lowest common denominator for all sort of spaces to be built on.

2. Terminology¶

• A space is a pubsub node (Publish-Subscribe (XEP-0060) [2]) acting as the "parent" of several related rooms and other entities.
• A spaces service is a pubsub service that contains spaces, i.e., it is the parent of multiple spaces.

3. Node Configuration¶

To be effectively usable as a space, a pubsub node must be configured in the way described by the following table below. We here introduce the notion of space exposure. A space can be public, meant to be joinable by anyone; or private, meant to be joined at the discretion of the node owner.

NB: this specification is made to be fully compatible with Publish-Subscribe (XEP-0060) [2] without special server support. Ideally, additional functionality, yet to be described in subsequent specifications, would allow:

• To notify the subscribers of a space node of new subscriptions (and not just the owner). This is especially useful for private spaces.
• To ensure that a private space node is hidden from the list of nodes of a pubsub service, similar to the muc#roomconfig_publicroom configuration option for Multi-User Chat (XEP-0045) [1].

4. Discovering support¶

In order to act as a space service, a pubsub service MUST implement and advertise in its disco#info (Service Discovery (XEP-0030) [3]) the following features described in Publish-Subscribe (XEP-0060) [2] (prepended by http://jabber.org/protocol/pubsub#):

• subscribe
• create-nodes
• delete-nodes
• config-node
• meta-data
• delete-items
• retract-items
• multi-items
• item-ids
• manage-subscriptions
• retrieve-items

For better usability, it SHOULD also implement:

• member-affiliation
• modify-affiliations
• retrieve-affiliations
• get-pending

5. Protocol¶

<iq type='get'
    from='emacs-user@megacorp.example.com/cool-client'
    to='megacorp-pubsub.example.com'
    id='spaces-items'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <!-- Optional filter, if supported -->
    <filter xmlns='urn:xmpp:pubsub-filter:0'>
      <x xmlns='jabber:x:data' type='submit'>
        <field var='FORM_TYPE' type='hidden'>
          <value>urn:xmpp:pubsub-filter:0</value>
        </field>
        <field type='list-multi' var='included-types'>
          <value>urn:xmpp:spaces:0</value>
          <value/>
        </field>
      </x>
    </filter>
  </query>
</iq>

<iq type='result'
    to='emacs-user@megacorp.example.com/cool-client'
    from='megacorp-pubsub.example.com'
    id='spaces-items'>
  <item jid='megacorp-pubsub.example.com'
        node='dev'
        name='The developers corner'/>
  <item jid='megacorp-pubsub.example.com'
        node='sales'
        name='Sales team'/>
  <item jid='megacorp-pubsub.example.com'
        node='management'
        name='The bosses lounge'/>
</iq>

<iq type='get'
    from='emacs-user@megacorp.example.com/cool-client'
    to='megacorp-pubsub.example.com'
    id='space-metadata'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='dev'/>
</iq>

<iq type='result'
    from='megacorp-pubsub.example.com'
    to='emacs-user@megacorp.example.com/cool-client'
    id='space-metadata'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='dev'>
    <identity category='pubsub' type='leaf'/>
    <feature var='http://jabber.org/protocol/pubsub'/>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>http://jabber.org/protocol/pubsub#meta-data</value>
      </field>
      <field var='pubsub#type'>
        <value>urn:xmpp:spaces:0</value>
      </field>
      <field var='pubsub#creator' label='Node creator' type='jid-single'>
        <value>lead-dev@megacorp.example.com</value>
      </field>
      <field var='pubsub#title'>
        <value>The developers corner</value>
      </field>
      <field var='pubsub#owner' label='Node owners' type='jid-multi'>
        <value>lead-dev@megacorp.example.com</value>
        <value>lead-dev-friend@megacorp.example.com</value>
      </field>
      <!-- other fields of the pubsub#meta-data FORM_TYPE !-->
    </x>
  </query>
</iq>

<iq type='get'
    from='emacs-user@megacorp.example.com/cool-client'
    to='megacorp-pubsub.example.com'
    id='space-items'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='dev' />
  </pubsub>
</iq>

<iq type='result'
    from='megacorp-pubsub.example.com'
    to='emacs-user@megacorp.example.com/cool-client'
    id='space-items'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='dev'>
      <item id='boring-software@conference.megacorp.example.com'>
        <conference xmlns='urn:xmpp:bookmarks:1'
                    name='ERP 3000'
                    autojoin='true' />
      </item>
      <item id='programming-socks@conference.megacorp.example.com'>
        <conference xmlns='urn:xmpp:bookmarks:1'
                    name='Share your best programming socks deal HERE'>
          <extensions>
            <pinned xmlns='urn:xmpp:bookmarks-pinning:0'/>
          </extensions>
        </conference>
      </item>
      <item id='editors@conference.megacorp.example.com'>
        <conference xmlns='urn:xmpp:bookmarks:1'
                    name='Settling the text editor wars'>
        </conference>
      </item>
      <item id='https://megacorp.example.com/dev-team-presentation'>
        <x xmlns='jabber:x:oob'>
          <url>https://megacorp.example.com/dev-team-presentation</url>
        </x>
      </item>
      <item id='some-hash'>
        <subscription xmlns="urn:xmpp:pubsub:subscription:0"
                      server="megacorp-pubsub.example.com"
                      node="dev-announcements" />
      </item>
      <!-- other items -->
    </items>
  </pubsub>
</iq>

<iq from='emacs-user@megacorp.example.com/cool-client'
    to='programming-socks@conference.megacorp.example.com'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<iq from='programming-socks@conference.megacorp.example.com'
    to='emacs-user@megacorp.example.com/cool-client'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
  <!-- [...] -->
  <feature var='urn:xmpp:spaces:0'/>
  <x xmlns='jabber:x:data' type='result'>
    <field var='FORM_TYPE' type='hidden'>
      <value>urn:xmpp:spaces:0</value>
    </field>
    <field var='parent' label='Space parent''>
      <value>xmpp:megacorp-pubsub.example.com?;node=dev</value>
    </field>
  </x>
  <x xmlns='jabber:x:data' type='result'>
    <field var='FORM_TYPE' type='hidden'>
      <value>http://jabber.org/protocol/muc#roominfo</value>
    </field>
    <!-- ... -->
    <field var='muc#roominfo_pubsub' label='Associated pubsub node'>
      <value>xmpp:megacorp-pubsub.example.com?;node=dev</value>
    </field>
  </x>
</query>
</iq>

6. XMPP Registrar Considerations¶

7. Security considerations¶

Security considerations are related to access control, and are out of scope of this document.

8. XML Schema¶

No new schema is defined in this document.

Appendices

Appendix A: Document Information¶

Series

XEP

Number

0503

Publisher

XMPP Standards Foundation

Status

Experimental

Type

Standards Track

Version

0.2.0

Last Updated

2025-09-13

Approving Body

XMPP Council

Dependencies

XMPP Core, XMPP IM

Supersedes

None

Superseded By

None

Short Name

spaces

Source Control

HTML

This document in other formats: XML  PDF

Appendix B: Author Information¶

Nicolas Cedilnik

Email

nicoco@nicoco.fr

JabberID

nicoco@nicoco.fr

Timothée Jaussoin

Email

edhelas@movim.eu

JabberID

edhelas@movim.eu

URI

https://edhelas.movim.eu

Appendix C: Legal Notices¶

Appendix D: Relation to XMPP¶

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.

Appendix E: Discussion Venue¶

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>.

Appendix F: Requirements Conformance¶

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.

Appendix G: Notes¶

Appendix H: Revision History¶

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

1. Version 0.2.0 (2025-09-13)¶

   Rewrite using pubsub semantics.

   nc
2. Version 0.1.0 (2025-03-11)¶

   Promoted to Experimental

   XEP Editor: dg
3. Version 0.0.1 (2025-02-23)¶

   Initial version.

   nc

Appendix I: Bib(La)TeX Entry

@report{cedilnik2025spaces,
  title = {Server-side spaces},
  author = {Cedilnik, Nicolas and Jaussoin, Timothée},
  type = {XEP},
  number = {0503},
  version = {0.2.0},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-0503.html},
  date = {2025-02-23/2025-09-13},
}

END