13 Sep
2025
13 Sep
'25
1:36 p.m.
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
13 Sep
13 Sep
1:41 p.m.
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
3:36 p.m.
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
15 Sep
15 Sep
10:29 p.m.
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/bd3c9a933995c78b0624a67f5a2de…
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/47658a8739a88592dfe62a4f43cd1…
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/baf0c711de29640c378057779184f…
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/ec9bc3eb4521be321a5d0a211eed4…
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/9e44800b7c99f3719b9a3726fdb68…
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/e7a4efd287ae56b3843becc247f50…
Best,
-- nicoco
16 Sep
16 Sep
9:55 a.m.
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 :
Fair. It's mostly semantic, I would have use a dedicated <pubsub
jid="abc(a)eample.net" node="xyz" /> here, but I can live with the
current element.
Cool.
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
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/bd3c9a933995c78b0624a67f5a2de…
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. 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/ec9bc3eb4521be321a5d0a211eed4…
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/9e44800b7c99f3719b9a3726fdb68…
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/e7a4efd287ae56b3843becc247f50…
13 Sep
13 Sep
3:48 p.m.
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.
15 Sep
15 Sep
10:31 p.m.
Hi singpolyma and thanks for your feedback.
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/b798aad90a42c171f5406cc0f1686…
Oops,
fixed.
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.
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
16 Sep
16 Sep
4:04 p.m.
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.
10:23 a.m.
On Sat, 13 Sept 2025 at 14:48, Stephen Paul Weber <singpolyma(a)singpolyma.net>
wrote:
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.
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.
4:10 p.m.
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).
54
days inactive
57
days old
9 comments
4 participants
participants (4)
-
Dave Cridland -
Goffi -
Nicolas Cedilnik -
Stephen Paul Weber