15 Sep
2025
15 Sep
'25
10:29 p.m.
Hi goffi and thanks for your feedback.
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.
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…
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).
Fair enough, added.
https://github.com/xsf/xeps/pull/1461/commits/47658a8739a88592dfe62a4f43cd1…
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.
Indeed. Fixed!
https://github.com/xsf/xeps/pull/1461/commits/baf0c711de29640c378057779184f…
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.
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.
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…
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?
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…
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…
Best,
-- nicoco