XEP-0503: Spaces update proposal
Hi all, I just submitted a revision to XEP-0503: Spaces. This is something edhelas and I have been working on last week. I intend to implement it in slidge, and he intends to implement UI for it in movim. It is an almost complete rewrite vs the current state, which should not be an issue since it has not been implemented anywhere yet. I tried to incorporate the feedback I got, not only from the mailing but in various MUCs and private conversations I had about the XEP here and there. In short, a space is now just a pubsub node with appropriate configuration and payload, and a space service is a pubsub service with feature requirements. As per the previous revision, the goal of this XEP is to establish a minimal viable protocol for clients and servers to build around the general concept of grouping several entities together. It requires little to no additional support server-side and should work, in a very basic form, with what's already available out there. I believe, that, even in this basic form, it would be nice to have. edhelas and I will also submit soon(ish) another XEP which could be _a_ way of defining how space-wide affiilations/roles/hats could work, by using a "space's main MUC". That would allow for both optimising presence traffic and enforcing consistency between the various rooms of a space. This, of course, would require some additional server and client support, but it looks like we can do something that is relatively usable on any MUC-supporting client. I think it is best to have this in a separate XEP, for future-proofness, since GC3 is just around the corner. ;o) Let me know what you think. -- nicoco
Of course I forgot to include the links to the pull request and the rendered version in my previous email… https://github.com/xsf/xeps/pull/1461 https://nicoco.fr/xep-0503.html Oopsies. -- nicoco
Le samedi 13 septembre 2025, 13:36:50 heure d’été d’Europe centrale Nicolas Cedilnik a écrit :
Hi all,
I just submitted a revision to XEP-0503: Spaces. This is something edhelas and I have been working on last week. I intend to implement it in slidge, and he intends to implement UI for it in movim.
[SNIP]
Hi Nicoco and Edhelas, thanks for your work, it's really nice to see that you've moved to Pubsub. In §5.2 it may be worth noting that XEP-0497 lets you retrieve metadata directly with the disco#items request, avoiding to request each individual node. In §5.3 you may want to mention XEP-0465 (Pubsub Public Subscriptions) as it solves issues with XEP-0330 (but requires server support, so XEP-0330 is useful if XEP-0465 is not supported by the server). In §5.4 you're making a confusion between disco#items request and pubsub get request. A disco#items request doesn't return the payload; it's a pubsub get that you want to do here. In §5.4 I don't see the point of using a <subscription> element to indicate a pubsub node. I mean, we only want the JID and node here, but it's ultimately the user/client who decides if they want to subscribe or not. It's just semantic, not a big deal though. In §5.5 I think that `muc#roominfo_pubsub` is a poor choice. IMO it should be a dedicated field that could be used for all items MUC, Pubsub, whatever alike (something like `{urn:xmpp:spaces:0}parent`). And it should be a list of strings, because a MUC or a node could be part of several spaces. It seems not possible with this version to "hide" restricted spaces (for instance, in a space there could be rooms restricted to moderators and they may not want it to be visible), except by using a private space only for moderators (which is an option, but makes discovery more complicated). This could be done by using child nodes with XEP-0496. Not that it's really needed at this point, but it would be nice to leave the door open for child spaces. Another thing I would like to see is the possibility to add URLs, notably HTTP ones (e.g., if I make a space about my XMPP client, I want to add the official website, my blog, and maybe link my account on Mastodon or other platforms). I like this version a lot more than the previous one, and the implementation seems easier as it now relies on the standard Pubsub service. Great work! Best, Goffi
Hi goffi and thanks for your feedback.
In §5.2 it may be worth noting that XEP-0497 lets you retrieve metadata directly with the disco#items request, avoiding to request each individual node.
I did not find where that was possible with XEP-0497, which I think is interesting to mention nevertheless. Can you point me to where getting metadata with disco#items request is possible in the text? I agree that subscribing to metadata updates is very interesting so I did mention XEP-0497 in "joining a space" nevertheless. https://github.com/xsf/xeps/pull/1461/commits/bd3c9a933995c78b0624a67f5a2de2...
In §5.3 you may want to mention XEP-0465 (Pubsub Public Subscriptions) as it solves issues with XEP-0330 (but requires server support, so XEP-0330 is useful if XEP-0465 is not supported by the server).
Fair enough, added. https://github.com/xsf/xeps/pull/1461/commits/47658a8739a88592dfe62a4f43cd1d...
In §5.4 you're making a confusion between disco#items request and pubsub get request. A disco#items request doesn't return the payload; it's a pubsub get that you want to do here.
Indeed. Fixed! https://github.com/xsf/xeps/pull/1461/commits/baf0c711de29640c378057779184fb...
In §5.4 I don't see the point of using a <subscription> element to indicate a pubsub node. I mean, we only want the JID and node here, but it's ultimately the user/client who decides if they want to subscribe or not. It's just semantic, not a big deal though. The reason is mostly syntax re-use. But it is a SHOULD, so it is not entirely forbidden to use another syntax to include pubsub nodes, right? I guess it would be nice if the element had a "name" or "description" element too. In §5.5 I think that `muc#roominfo_pubsub` is a poor choice. IMO it should be a dedicated field that could be used for all items MUC, Pubsub, whatever alike (something like `{urn:xmpp:spaces:0}parent`). And it should be a list of strings, because a MUC or a node could be part of several spaces.
I made it a dedicated data form and mentioned muc#roominfo_pubsub as a fallback (compatible with current MUC service implementations). I agree that a dataform allows a consistent way for entities to advertise their parents, which is a good idea. https://github.com/xsf/xeps/pull/1461/commits/ec9bc3eb4521be321a5d0a211eed4c... I am reluctant to allowing several parent spaces though, this sounds like a can of worms for clients to offer a consistent UI around. You could have additional spaces in other custom fields (which could be part of another XEP) if you have a use-case for this?
This could be done by using child nodes with XEP-0496. Not that it's really needed at this point, but it would be nice to leave the door open for child spaces.
Deal! I mentioned it. https://github.com/xsf/xeps/pull/1461/commits/9e44800b7c99f3719b9a3726fdb68d...
Another thing I would like to see is the possibility to add URLs, notably HTTP ones (e.g., if I make a space about my XMPP client, I want to add the official website, my blog, and maybe link my account on Mastodon or other platforms).
The space node can contain whatever, I added an <oob> element to point to a web site, does that work for you? https://github.com/xsf/xeps/pull/1461/commits/e7a4efd287ae56b3843becc247f50f... Best, -- nicoco
Hi Nicoco, thanks for having considered my feedback. Le lundi 15 septembre 2025, 22:29:02 heure d’été d’Europe centrale Nicolas Cedilnik a écrit :
I did not find where that was possible with XEP-0497, which I think is interesting to mention nevertheless. Can you point me to where getting metadata with disco#items request is possible in the text? I agree that subscribing to metadata updates is very interesting so I did mention XEP-0497 in "joining a space" nevertheless.
https://github.com/xsf/xeps/pull/1461/commits/bd3c9a933995c78b0624a67f5a2de2...
My bad, I was thinking about XEP-0499 (Pubsub Extended Discovery), with it you can specify with the form the `full_metadata` boolean which give you the metadata in the same request. So in a single request you get data such at `title` and `pubsub#type` of the nodes, instead of doing X requests.
[SNIP] Fair enough, added.
[SNIP]
Indeed. Fixed!
Thanks!
In §5.4 I don't see the point of using a <subscription> element to indicate a pubsub node. I mean, we only want the JID and node here, but it's ultimately the user/client who decides if they want to subscribe or not. It's just semantic, not a big deal though. The reason is mostly syntax re-use. But it is a SHOULD, so it is not entirely forbidden to use another syntax to include pubsub nodes, right? I guess it would be nice if the element had a "name" or "description" element too.
Fair. It's mostly semantic, I would have use a dedicated <pubsub jid="abc@eample.net" node="xyz" /> here, but I can live with the current element.
I made it a dedicated data form and mentioned muc#roominfo_pubsub as a fallback (compatible with current MUC service implementations). I agree that a dataform allows a consistent way for entities to advertise their parents, which is a good idea.
https://github.com/xsf/xeps/pull/1461/commits/ec9bc3eb4521be321a5d0a211eed4c...
OK. I've never used the `muc#roominfo_pubsub`, so I'm not sure if there is any use case conflict or not. Probably not.
I am reluctant to allowing several parent spaces though, this sounds like a can of worms for clients to offer a consistent UI around. You could have additional spaces in other custom fields (which could be part of another XEP) if you have a use-case for this?
I can see a few, but niche. For instance in my client there are several frontend, I could make a space for the web frontend, and another for the desktop one, and both would have the same official website/support room. But that's probably over-engineering and I understand your position. If the need arises in practice, we can reconsider then, or use another field as you suggest.
This could be done by using child nodes with XEP-0496. Not that it's really needed at this point, but it would be nice to leave the door open for child spaces.
Deal! I mentioned it.
https://github.com/xsf/xeps/pull/1461/commits/9e44800b7c99f3719b9a3726fdb68d...
Cool.
Another thing I would like to see is the possibility to add URLs, notably HTTP ones (e.g., if I make a space about my XMPP client, I want to add the official website, my blog, and maybe link my account on Mastodon or other platforms).
The space node can contain whatever, I added an <oob> element to point to a web site, does that work for you?
https://github.com/xsf/xeps/pull/1461/commits/e7a4efd287ae56b3843becc247f50f...
That looks good to me. I really like the XEP now! I'll have to think about a good UI/UX to integrate it in Libervia, and find time to implement it, but now that it's pubsub based, the XMPP part will be really easy on my side. Thanks again for your work. Best, Goffi
This clustering is already possible by setting up a dedicated MUC Service to group several rooms, but in practice, this is only doable by server administrators.
This isn't true though? I mean, as we've discussed I'm not aware of any currently *implementation* that allows it for non-admins, but that's a deficiency in the implementation, not the spec.
Discovering the children of a space uses a <tt>disco#items</tt> query directed a the node.
The example then goes on to show using pubsub-get-items not disco#items I am *very* concerned about moving from a protocol most clients support and have UI for (disco#items) to a protocol almost no clients supports and none will have UI for the datatype described here (pusbus-get-items on new format). This, to me, represents a large step backwards. I *do* appreciate that you're having sane spec hygiene and reusing namespaces instead of reinventing stuff here for syntax. But I think we get a lot further a lot quicker by using the mechanisms we've always had for hierarchical collections instead of making a new one.
Hi singpolyma and thanks for your feedback.
This clustering is already possible by setting up a dedicated MUC Service to group several rooms, but in practice, this is only doable by server administrators.
This isn't true though? I mean, as we've discussed I'm not aware of any currently *implementation* that allows it for non-admins, but that's a deficiency in the implementation, not the spec.
This is what I meant by "in practice", but fair enough, I updated the introduction to reflect that this is not strictly forbidden. https://github.com/xsf/xeps/pull/1461/commits/b798aad90a42c171f5406cc0f16869...
Discovering the children of a space uses a <tt>disco#items</tt> query directed a the node.
The example then goes on to show using pubsub-get-items not disco#items Oops, fixed. I am *very* concerned about moving from a protocol most clients support and have UI for (disco#items) to a protocol almost no clients supports and none will have UI for the datatype described here (pusbus-get-items on new format). This, to me, represents a large step backwards.
Clients have UI for "list all the public MUCs of this MUC service", and this specification does not change anything about that. Over that very basic form of grouping rooms, this specification makes it possible to: * subscribe to updates of a space (as opposed to polling content), which is desirable in my humble opinion; * have other things than rooms in a space (maybe it is not strictly forbidden to return other things than rooms in disco#items of a MUC service, but are we sure that current client implementations will handle that nicely?) On top of that, if having "MUC service disco#items listing space elements" is deemed crucial, a server-side implementation could synchronize the state of a pubsub node with the MUC service rooms. We don't have existing implementations of "letting regular users create and manage MUC services" anyway. Best, -- nicoco
Clients have UI for "list all the public MUCs of this MUC service"
I mean it's nothing to do with MUCs or MUC services. disco#items is a generic hierarchical federated "lists of things" protocol which can include anything including but not limited to MUCs (since they have JIDs) or PubSub nodes (since they have JID + node), and also "other lists" (hence hierarchical). Most clients for decades have had a UI to browse any such hierarchical structures. The original draft of this XEP documented this existing protocol for people who might not have realised its relation to the stated use case. Yes it's true that a "MUC service" also implements this protocol, and that in practise it often lists only public MUCs (though this can and is being changed) and that as a result a "MUC service" happens to conform to the original draft (giving us existing browsable compliant spaces like xmpp.org and joinjabber.org) however this doesn't mean that using disco#items requires MUCs or MUC services at all.
On Sat, 13 Sept 2025 at 14:48, Stephen Paul Weber <singpolyma@singpolyma.net> wrote:
This clustering is already possible by setting up a dedicated MUC Service to group several rooms, but in practice, this is only doable by server administrators.
This isn't true though? I mean, as we've discussed I'm not aware of any currently *implementation* that allows it for non-admins, but that's a deficiency in the implementation, not the spec.
OK, I'll bite. Given a MUC service requires DNS and a matching X.509 cert and private key, how is this going to be available for anyone but a trusted administrator of a server? I mean, you should be very pedantic and suggest that this isn't an entirely full administrator because they could only create arbitrary MUC services, but it's got to be some kind of highly elevated permissions, surely? Or am I misunderstanding what's required here? Dave.
Given a MUC service requires DNS and a matching X.509 cert and private key, how is this going to be available for anyone but a trusted administrator of a server?
Creating a new Slack space also requres a new DNS (subdomain of slack.com), matching X.509 cert and private key, and yet they don't require people to be "a trusted administrator" of slack to create them. Lots of hosting services allow virtual name creation by users (possibly certain class of users, paying, etc, but this is up to service policy).
participants (4)
-
Dave Cridland -
Goffi -
Nicolas Cedilnik -
Stephen Paul Weber