28 Apr
2026
28 Apr
'26
6:38 p.m.
On Tue, 28 Apr 2026 at 16:02, Marvin W. via Standards <standards(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org