On Tue, 28 Apr 2026 at 16:02, Marvin W. via Standards <standards@xmpp.org> wrote:
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.
I think that's a reasonable option. My concern would be that we will (eventually) need a profile to unify them into a "New MUC" baseline.
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
There's another part, which is limitations of '45, and requirements for New MUC. I think these are probably the most important part - if we can collate and agree those, then we can work to solve them.
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.
Right. 1 is fairly obvious (and exists in several quasi-MUC implementations in some form). 2 is a direct lift from MIX, I think.
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.
Right, so you have to have nicknames be unique in a room if you want '45 compatibility. And we absolutely require that, I think, at least in the early phases. The way '45 combines a variable name with an address is problematic, and causes us to do various workarounds in several places. As an example that's recently been raised, we can't block by full jid on our home server because the blockee can simply change their nickname. But also, resource strings are canonicalized and restricted in ways that nicknames are not - and vice-versa. As a less esoteric example, a 'DM' in a MUC from someone who changes their nickname is just annoying to handle cleanly in a client. I think if we were designing MUC from scratch right now, we'd simply use this addressing.
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.
It's intentionally very little, and that might seem weird so let me explain: If we want to include offline presence and similar for bare jid sessions from the outset, then I think we need something here. The included concept is close to the absolute bare minimum I could think of. I came up with something even smaller to begin with, but I felt it was too error prone (it was essentially "server doesn't bounce groupchat and advertises that, and client joins with an iq"). However, once we have this basic construct in place, we can start to build quite a bit more on it, for example, push notifications, better handling of references/mentions/etc, and even the long-forgotten inbox concept, and so on. I think these are really important to get right, and having a framework early on that we can experiment with is useful.
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.
I don't wholly disagree as far as 1+2 are concerned - I think those feel fairly straightforward to pull out ifthat's what Council want. I suspect 3 and 4 more or less have to go together, and probably alongside the requirements part. Dave.
Marvin
On Fri, 2026-04-24 at 10:26 +0000, Daniel Gultsch wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: New MUC Abstract: This document specifies an enhanced Multi-User Chat protocol that is broadly backwards compatible with that of XEP-0045, but adds a number of key improvements.
URL: https://xmpp.org/extensions/inbox/new-muc.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org