[jdev] [MUC] in-room sessions and Non-Anonymous

Dave Cridland dave at cridland.net
Tue Jun 11 16:54:12 UTC 2013

On Tue, Jun 11, 2013 at 5:38 PM, Bartosz Małkowski <bmalkowski at tigase.pl>wrote:

> Hi
> I have a problem.
> Our MUC Component supports entering to room from many resources (the same
> bareJID) with the same nickname.
> I don't know what should be sent in attribute jid of element <item/> when
> room is Non-Anonymous:
> <presence
>     from='coven at chat.shakespeare.lit/thirdwitch'
>     id='17232D15-134F-43C8-9A29-61C20A64B236'
>     to='crone1 at shakespeare.lit/desktop'>
>   <x xmlns='http://jabber.org/protocol/muc#user'>
>     <item affiliation='none'
>           jid='hag66 at shakespeare.lit/pda'
>           role='participant'/>
>   </x>
> </presence>
> Let me explain:
> To room joins:
> a at b/1 and a at b/2 with nickname XXX.
> 1. New occupant joins to room, then MUC must send to him presence of
> occupant "XXX".
> Which fullJID should be in attribute jid? Or maybe bareJID?
> Or maybe two <item/> with both fulljids?
> Or maybe two presences from XXX (with one <item/> element)?

Anything you like as long as it conforms.

I think M-Link picks one fairly arbitrarily, and Prosody might well do the
same. Bare jid seems sensible too, and indeed in general rather than just
for the nick-share case.

> 2. a at b/1 change his presence. What MUC should send to all occupants:
> bareJID, fullJID of a at b/1, two <items/>?

Same as above. I *think* that M-Link just sends individual presence changes
through, so if nick-shares are alternating, the jid will also change.

The more interesting question is what to do with private messages, or -
worse - pass-through <iq/> stanzas.

Isn't life fun when you take a step or two beyond the standards? :-)

FWIW, this all gets even more fun if you're nick-sharing based on role,
rather than merely bare jid. So, for example, if you have a "MedEvac"
nickname, which can be used by any jid which has an approved (non-XMPP)
MedEvac role. You may well want the real jid exposed, still, but it's not
at all clear how.

What this exposes is that when MUC was designed, it conflated two
orthogonal things - addressing and naming. This was itself fine, when there
was a 1:1 relationship - but the moment you break that, that causes some
interesting fractures.

Obviously we don't actually want to break compatibility either - otherwise
the solution is rather simple - but what we might want to do is think about
the really hard cases (like the MedEvac one I invented above) and figure
out what *should* happen there. One thing that would be sensible is if
clients could indicate that they understood nick-sharing, and have
additional information exposed to them.

I should really write this up properly...

But in the meantime, just do anything that works as long as it's
indistinguishable to clients from the single-fulljid-per-nick case.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20130611/d57e1bad/attachment.html>

More information about the JDev mailing list