29 Apr
2026
29 Apr
'26
11:31 p.m.
On Wed, 29 Apr 2026 at 12:39, Marvin W. via Standards <standards(a)xmpp.org>
wrote:
Hi,
On Tue, 2026-04-28 at 18:38 +0100, Dave Cridland wrote:
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.
That's a good point, so let me go through them:
All my points are excellent. Try not to sound so surprised. ;-)
2. MUC1 occupant addressing is also the nickname -
this is bad, because
when the nickname changes so does the JID, and it also restricts the form
of nicknames in unexpected ways.
"is bad" as I said is not really a good motivation. I agree that if we
were to redo MUC from scratch right now, we likely would use the occupant
id in the resource, mostly because it feels the right way to do it.
Can you outline that "restricts the form of nicknames in unexpected ways"?
Is that referring to clients and servers still relying on resourceprep when
the RFC is clear that resource is a PRECIS OpaqueString (which has almost
no limitations other than forbidding control characters, which seems
sensible for nicknames). Can you outline issues that are caused by nickname
changes causing JID changes which are fully resolved by not having that? I
think those should be in the requirements (e.g. allow MUC participants to
block other participants individually), because there might be other,
potentially better ways to fix those issues.
I think that combining addressing and visual naming is bad in principle,
and I think stable addressing for occupants is in general terms a good
thing.
But, you're quite right that higher level requirements are probably useful
here.
5. Presence-based joining is not (comfortably)
compatible with "sparsely
online" clients such as mobile; when not online a client is not an occupant
- long-term engagement with a chatroom is complicated as a result, so we
should fix this.
In my experience, my mobile is actually the least sparsely online client,
at least from a MUC perspective. I might be temporarily disconnected due to
network unavailable like in tunnels, but that's just for a short time and
either TCP is still alive or I can resume the sessions using XEP-0198. But
even if those short disconnects would result in being disconnected from the
room, I would certainly want to fix this also for when I joined a room
ephemerally.
In contrast, it's my desktop computer that is typically offline for half
of the day, which results in heavy use of MUC-MAM. But at least for me,
this seems to be working reasonably well.
That's probably all true, and QUIC is very shiny here too. My experience
may well be coloured by clients which are not always-on - that is, clients
which are not able to maintain a continuous XMPP connection as we can on
Android.
But also long-term engagement has a variety of meanings here, and again I
should absolutely expand on them. By way of examples, if my server had a
constant view of messages, and I were visible as an occupant even when
devices were offlne, I could still get push notifications for messages
mentioning my name even if not an explicit mention, or I could get pushes
for a mere mention of, say, Wimsy.
From the other perspective, I can't tell if you dropped offline because you
went into a tunnel and lost your session, or whether you dropped offline
because you've left the chatroom in disgust at my continually mentioning
Wimsy.
9. The same room JID and state should be usable by
both MUC1 and MUC2.
Fully agree on state, not so much necessarily on JID. I could perfectly
imagine MUC1 and MUC2 to use different JIDs internally, but then
discoverability becomes an issue to solve. Given that your current proposal
achieves the same room JID by adding restrictions to the users' nicknames,
I'm also not sure that this is really necessary. Maybe one might want to
rephrase this
I think it's a SHOULD for the jid. I agree that huge chatrooms can't
mandate unique nicknames effectively, in which case they can't be exposed
on the same jid as MUC1 fully transparently. And maybe that's OK, since
huge chatrooms wouldn't work anyway on MUC1. But, for example
xsf(a)muc.xmpp.org probably needs to keep its bare jid address to allow
transition sensibly.
So maybe we say that while some MUC2 rooms might not be able to be
presented at MUC1, this is often desirable especially during the transition
period?
10. MUC1 presence is very noisy; MUC2 should provide a way to reduce or
elide presence entirely.
Fully agree.
Now the remaining points either describe status quo and mention it as
explicitly desirable (1, 3, 4, 7) or describe status quo without a clear
indication if that's meant to stay this way or changed as part of MUC2 (6,
8).
Do you agree that 1,3,4,7 are actually desirable to maintain?
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.
Except if we allow for an additional nickname outside the resource, even
for MUC1. I bring this up because if we solve this for MUC1 (e.g. by using
something like the XEP-0172 MUC support removed in version 1.1 of that XEP
but still used in the wild by some clients, notably Jitsi Meet), that
solution almost automatically reduces the importance of the resource in the
JID and thus makes a transition to occupant id in resource an easier step.
I'd lean away from introducing (or reintroducing) changes in MUC1 to ease
transition, because any client willing to adopt them might as well adopt
MUC2.
===
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.
That's not the only issue with DM in MUC and we might also want to ask the
question (similar to <iq> in MUC) if that's needed or wanted at all, or if
rather a protocol to allow an occupant to discover another occupants real
bare jid (with their consent) is reasonably suitable for what DM in MUCs
could be used.
I think DMs are useful things (even if I generally dislike them and want
them turned off). More generally, I think being able to direct traffic to
individual occupants is a useful feature beyond just messages. I don't
think we want to have to expose real jids to allow this.
MUC1 originally had occupant jids be a forwarding device to the real full
jid of the occupant. Then we introduced nick sharing as a bit of a hack,
and vCard handling and more of a hack still, and then we removed it all for
anonymous rooms, and then... Layers upon layers of hackery.
I'd like a more well-defined model in MUC2 which would allow for DMs (I
think that's the easy case) but also avatars, Jingle, and other things even
in anonymous rooms.
I do not have a design for this, though - I suspect it'll look like some
mixture of proxying and publishing, so for example we might either publish
an avatar to "your" occupant, or have the avatar request be proxied back to
your own bare jid, or both but you get to pick which.
Dave.