23 Feb
2025
23 Feb
'25
2:13 p.m.
Thank you singpolyma for a very prompt feedback.
In https://xmpp.org/extensions/xep-0045.html#disco-roomitems
Fetching the
list of rooms that are children of a space is done via a
disco#items directed at the JID of the space on the urn:xmpp:spaces:0
node. Using a node on top of the JID makes it possible for a space
to be a room itself, which is possible but not required by this
specification.
I don't think using a node is needed to fulfill this requirement. Any
MUCs found as items on a MUC would be members surely? And any items on
a space JID would be items in that space surely. An implementation MAY return a list of existing
occupants if that
information is publicly available, or return no list at all if
this
information is kept private.
So a spaces-capable public MUC room would return both its occupants and
its children rooms, all mixed up together? I can see that working, since
occupants have a resource part, while MUC rooms don't, so we have a
(fragile?) heuristic to discriminate the two. Also, maybe MUC services
actually do not implement this MAY for various reasons.
I am not against removing this node and just doing the disco#items dance
on the space JID without node. I put it there because I was worried
mixing occupants and children rooms would be a source of trouble for
clients. I wonder what other client devs think about this. Maybe no
actual implementation relies on disco#items queries on a room so it does
not matter?
If we decide a node *is* needed, I think the node
needs a name related
to what it is. Naming the node the same name you suggest for a list of
spaces to list the items in a space is confusing IMO.
Maybe we won't need it at all as you, but if we do, let's make it
"urn:xmpp:space" (singular) then?
-- nicoco