On Tue, 28 Apr 2026 at 16:02, Marvin W. via Standards <[email protected]>
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 -- [email protected]
> > To unsubscribe send an email to [email protected]
> _______________________________________________
> Standards mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
