[jdev] Question on Presence, Invisibility and MUC

Waqas Hussain waqas20 at gmail.com
Fri Oct 12 16:15:32 UTC 2012


On Fri, Oct 12, 2012 at 7:39 PM, Daniel Dormont
<dan at greywallsoftware.com> wrote:
> Hi all,
>
> In my XMPP application, users can exchange both private messages and
> presence and join MUCs. Ok, simple enough. I've implemented invisibility
> according to XEP-0126. I'd like the users to be still able to join MUCs
> while invisible, though. The issue I'm running into is that the first step
> in going invisible is sending an unavailable presence for broadcasting to
> all contacts: <presence type='unavailable'/>
>
> Unfortunately for me, this has the additional effect of kicking the user out
> of any MUCs they'd joined in that particular session. I've already figured
> out how to tweak the privacy list so users can join MUCs while invisible to
> individual contacts, basically it just looks like
>
>     <list name='invisible'>
>       <item type='jid'
>             value='conference.mydomain'
>             action='allow'
>             order='1'>
>         <presence-out/>
>       </item>
>       <item action='deny' order='2'>
>         <presence-out/>
>       </item>
>     </list>
>
> But I'm running into this problem when the user tries to go "globally"
> invisible while already in one or more MUCs. Is there any way around this?
> My initial thought was to direct the unavailable presence to only the
> primary (IM) domain rather than having no "to" as indicated in the XEP, but
> that doesn't seem to broadcast to anybody, so contacts who already thought
> the user was online will continue to think so.
>
> Is there any way around this? Or will I have to change my approach to
> invisibility?
>

Blocking out-going presence to the chatrooms before you send
unavailable presence might work. This is a hack which depends on the
server not sending unavailable presence to blocked contacts.

Directed presence is almost completely separate from normal presence
status, with this one exception: unavailable presence broadcasts. I'm
beginning to think this is more harmful than helpful.

Relevant spec section: http://tools.ietf.org/html/rfc6121#section-4.6.3

> thanks,
> Dan
>

--
Waqas Hussain


More information about the JDev mailing list