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@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.