15 Sep
2025
15 Sep
'25
10:31 p.m.
Hi singpolyma and thanks for your feedback.
This is what I meant by "in practice", but fair enough, I updated the
introduction to reflect that this is not strictly forbidden.
https://github.com/xsf/xeps/pull/1461/commits/b798aad90a42c171f5406cc0f1686…
Oops,
fixed.
This
clustering is already possible by setting up a dedicated MUC
Service to group several rooms, but in practice, this is only doable
by server administrators.
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. Discovering
the children of a space uses a <tt>disco#items</tt> query
directed a the node.
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.
Clients have UI for "list all the public MUCs of this MUC service", and
this specification does not change anything about that. Over that very
basic form of grouping rooms, this specification makes it possible to:
* subscribe to updates of a space (as opposed to polling content),
which is desirable in my humble opinion;
* have other things than rooms in a space (maybe it is not strictly
forbidden to return other things than rooms in disco#items of a MUC
service, but are we sure that current client implementations will
handle that nicely?)
On top of that, if having "MUC service disco#items listing space
elements" is deemed crucial, a server-side implementation could
synchronize the state of a pubsub node with the MUC service rooms. We
don't have existing implementations of "letting regular users create and
manage MUC services" anyway.
Best,
-- nicoco