[Standards] Re: Proposed XMPP Extension: New MUC

Hi, First, thanks Dave for starting this work. I generally appreciate someone again making an effort to fix issues with MUC. 👏 As I had expressed before, I feel that the things listed in this proposal are somewhat adjacent and combining them in a single proposal will make development in the experimental phase significantly more complicated. This proposal has essentially four parts to it: 1. Join mode where less presences are received 2. Ability to reveal jid in semi-anon rooms and to block join if the room (unexpectedly) is not semi-anon 3. Switch position of nickname from resource in occupant jid to payload xml element and occupant-id from payload xml element to resource in occupant jid 4. Stay joined while offline / MUC-PAM I consider 1 and 2 pretty easy to implement both on servers and clients. Both have a pretty clear motivation and usecase. I am also well aware of immediate interest of 1 in the community. In contrast 3 has all kinds of things to consider, especially on the server side when thinking about compatibility with MUC1. The motivation for this significant change is less obvious ("when the nickname changes so does the JID", why is this bad?) and in practice there likely won't be a lot of user-visible improvements. I agree it would be nice if we had that, but maybe directly going there is the wrong way and likely some experimentation is needed/wanted. Notably, I would want to have nicknames collisions made possible (which is needed for large rooms to become practical), which is explicitly excluded in the current proposal. Regarding 4, there is a bunch of complexity to it, both on clients and servers. And again it's unclear how big the practical improvement is for clients over using MUC-MAM and being temporarily offline. I would therefor opt to split this into independent XEPs (with independent namespaces not affecting each other), so they can be developed and tested independently. Especially because I could imagine for 1 and 2 to reach a reasonable stable state pretty quickly. Having them depend on the more complex stuff being ready means to keep things from improving in practice. Marvin On Fri, 2026-04-24 at 10:26 +0000, Daniel Gultsch wrote: