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/bd3c9a933995c78b0624a67f5a2de2d28f119ee6 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="[email protected]" 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/ec9bc3eb4521be321a5d0a211eed4c73a3fc7100 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/9e44800b7c99f3719b9a3726fdb68d0cf2d51238 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/e7a4efd287ae56b3843becc247f50f5048c26d2b 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
