Hi singpolyma and thanks for your feedback.

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.

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/b798aad90a42c171f5406cc0f168694504c168ac

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