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