On Fri, Oct 12, 2012 at 12:15 PM, Waqas Hussain <[email protected]> wrote:
> On Fri, Oct 12, 2012 at 7:39 PM, Daniel Dormont > <[email protected]> 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 > > I think I need some more time to digest that section. There's something I still don't quite follow about it. But in the mean time, your trick of temporarily employing a privacy list that's the exact opposite of the normal invisibility one, worked fine, so thanks. dan > > thanks, > > Dan > > > > -- > Waqas Hussain > _______________________________________________ > JDev mailing list > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: [email protected] > _______________________________________________ >
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
