Le samedi 13 septembre 2025, 13:36:50 heure d’été d’Europe centrale Nicolas Cedilnik a écrit : 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

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