29 Apr
2026
29 Apr
'26
12:36 p.m.
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:
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.
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.
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
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).
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.
===
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.
Marvin