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/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.
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.
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…
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/e7a4efd287ae56b3843becc247f50…
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