So, when I've been thinking about this, I've generally come to the conclusion that MUC has a fairly chunky design flaw, which is that we conflated the addressing, and display, of occupants.
The "right" way of doing this would be to randomly assign the resource, and then have a distinct nickname, which might be non-unique. But I have no idea how to get there from where we are. I think your suggestion *almost* works for anonymous rooms: - Initial presence only lists each nickname once, for us. Maybe we could list occupants more than once for nick-shares, but that scares me somewhat. This means you'll only "see" one client through the MUC. - As you've pointed out, it's indistinguishable from a client changing caps, unless we start to read rather more into the node than perhaps we should. It all feels a bit heuristic to me. I can solve the second problem for anonymous rooms by giving them a jid; that could either be an in-room style jid or some other shadow jid on the MUC server. If it's an in-room jid, that allows us to not only track the different occupants using the same jid, but it also allows us to address them independently, which seems handy. It's halfway to the "right" design I outlined above. To put it another way, you make the anonymous case work by making all rooms non-anonymous, but the jid so revealed might itself be anonymized. The first issue needs an extension to solve; I think we need some additional gunk in the join for clients to indicate they'll be unfazed by having multiple occupants for the same nickname. Seems reasonable?
