[jdev] Question on Presence, Invisibility and MUC

Jonathan Dickinson jonathan at dickinsons.co.za
Wed Oct 24 21:27:03 UTC 2012


Just a thought, untested: re-join the rooms the user is on after going invisible?

-- Jonathan Dickinson

Date: Tue, 23 Oct 2012 08:56:57 +0300
From: blueobaid at gmail.com
To: jdev at jabber.org
Subject: Re: [jdev] Question on Presence, Invisibility and MUC

Hi Guys,
Can I know the procedure of creating a room please, I'm searching for it day long please help and do we have the delegate methods of creating a room and do other functions too... Please help me in taking a start in creating a room thank you.


On Mon, Oct 22, 2012 at 10:38 PM, Daniel Dormont <dan at greywallsoftware.com> wrote:


On Fri, Oct 12, 2012 at 12:15 PM, Waqas Hussain <waqas20 at gmail.com> wrote:


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



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: JDev-unsubscribe at jabber.org

_______________________________________________




_______________________________________________

JDev mailing list

Info: http://mail.jabber.org/mailman/listinfo/jdev

Unsubscribe: JDev-unsubscribe at jabber.org

_______________________________________________





_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-unsubscribe at jabber.org
_______________________________________________ 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jdev/attachments/20121024/e37a11cb/attachment.html>


More information about the JDev mailing list