Is there a way to determine which Mulit User Conferences (MUC) a user has joined? - xmpp

I wonder if there is a way to query the XMPP server (passing user JID?) to find out what chat room(s) this user is currently in? If not, can we query jabber server to get a list of all active chat rooms?
BTW we're running ejabber enabled for multiuser chat. A solution using a java library (smack?) would be ideal.

As mentioned by Joe Hildebrand, there is no such a standard feature as it is a privacy violation to allow that over XMPP, so you cannot expect to do that from Smack. Maybe with admin privilege you could have a custom protocol extension that does that but that seems risky.
However, at the server level, you should be able to write a custom module for ejabberd that will query or index all rooms users are in. This is not standard and there is plugin development involved.

There are two (maybe three) XMPP entities that have that information:
the XMPP MUC component which provides the MUC room
the users XMPP client (or better the XMPP library used by the user)
maybe the XMPP server(s) (but let's ignore that)
At the time of writing this, there is no standardized way (in terms of XMPP XEPs) to query that information. As Joe Hildebrand pointed out, this would result in a information leak which is not what we want in most cases.
But you can either extend the MUC component to provide that information (remember XMPP is easily extendable) or the XMPP client library. The usual approach would be via an iq get query. For example:
<iq type='get' from='juliet#capulet.lit/balcony' to='capulet.lit' id='q1'>
<query xmlns='http://jabber.org/protocol/muc#joinedrooms'/>
</iq>
The entities which support that query would then report back the joined rooms of the requested entity. Also they would may announce the http://jabber.org/protocol/muc#joinedrooms feature in their service discovery information.
Note that this is a fictional protocol extension meant as example. I have never seen it in real use
If the MUC component provides this feature then it's not controllable by the client if this information is exposed. But if the client provides this feature then of course he can control who can retrieve this information. You may decide what's the better approach in your case.

Getting all chat rooms is no problem, just use this query.
There seems to be already a question on how to retrieve rooms with smack. Look here.

Related

Leaving XMPP Room Permanently As a Member

We're implementing an xmpp client and we are using ejabberd as xmpp server.
We've implemented muc (multi user chat) functionalities to our app and everything is working fine , only thing we are having problem is a member to leave the group permanently.
I know in XEP 45 says if you want to leave the group just send the unavailable presence to room but this doesnt work in our case because our admins add users of the group to memberList
by sending the below xml:
<iq from='crone1#shakespeare.lit/desktop'
id='member1'
to='coven#chat.shakespeare.lit'
type='set'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='member'
jid='hag66#shakespeare.lit'
nick='thirdwitch'/>
</query>
</iq>
And when a member send unavailable presence, this doesnt affect the groups member list(Which is working as we wanted)
So we want to find a way for a member to remove himself/herself from group members list permanently so he/she wont be able to receive any messages from that group anymore
Is something like that possible? Can we remove ourself from groups member's list like whatsapp's leave chat functionality.
When user leaves room he will not receive messages anymore - XMPP MUCs are presence-based. "Member lists" are only for administrative purposes and does not control message receiving.
There are some another XMPP extension specifications designed with "persistent" member list in mind, for example MUC Light - it can be more suited for you needs.
As defined in XEP-0045, if the MUC admin added another user as member, that added user cannot remove himself as member.
However, as a default in XEP-0045, MUC members do not receive message. This brings me to think this is not the problem you are hitting.
I suggest that you use MUC/Sub as implemented in ejabberd and defined in this specification for more flexibility. It is 100% compliant with MUC specification, so MUC compliant client and MUC/Sub enhanced client can participate in the same workflow.
In your case, I think that you need to subscribe your users to the events he wants (message, possibly presence or configuration changes). Subscription can be handled by users so that user can also control unsubscribe. It should do exactly what you want.
You need ejabberd 16.09 to use that specification. MUC/Sub is defined here: https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/

Openfire: Create MUC Room with custom fields

First of all, I'd like to provide some background information: I want to exchange unstructured data between various clients using XMPP. Data sources are supposed to publish their data simply to Mulit-User-Chat rooms (XEP-0045) so that any interested client can register.
XMPP MUC services can have various chat rooms and in order to find the ones my data sources push information to, I'd like to set some custom identification for that room. I figured muc#roominfo_<custom_ident> with some custom value would be great to accomplish that.
For testing purposes I wrote an application that creates a MUC on an XMPP service. Authentication etc. all works fine. I am using Smack to communicate with the XMPP server and to create the room. When I create the room, I am adding a field to the form field I requested before containing my custom information. The MUC is created and accessible. Yet the created custom field is not returned when I perform a disco#info on the room's JID.
I tested this with a local installation of (3.8.2).
I just wonder, if this is an issue of Openfire, that custom form fields (XEP-0068 used here in XEP-0045) are not stored when the MUC is created or if it is just not allowed according to XEP-0045? I read the specification for MUCs and crucially the respective section but couldn't find any evidence that convinced me, that it is explicitly not possible to create such custom form fields for a MUC.
Maybe I just misunderstand something in the specification? Has anyone tried something similar and it's working? If it is an issue of Openfire, I could try a different XMPP server.

Facebook Chat limitations

My company develop a product for customer support on Facebook and we want to give the representatives a way to contact the customer via Facebook Chat.
I have read the Chat API documentations and it is not clear whether users MUST be friends on Facebook in order to chat or is it just enough they both installed a Facebook app? more limitations?
any insight will be appreciated.
Thanks in advance for you answers,
Yaniv Hakim
Facebook provides an XMPP port to the outside world while internally it implements MQTT. As per XMPP specs, messaging works between two entities without they being in each other roster list (friend/contact list). However, Facebook seems to have this limitation as part of their own business requirement. I think even GoogleTalk disallows this if two federated entities try to send message to each other without being on the roster list.
In short, yes you can just send the message. You don't need a presence authorization from someone in order to send messages to them (in XMPP world). HOWEVER, some services has a policy of requiring this, despite the fact that this is not mandated by the XMPP specifications.

Best way to integrate an XMPP Server into Webapplication

I'm working on a middle size community project, using php and the php framework symfony2 atm.
We are planning to integrate XMPP as a support chat and premium feature for our users. The users will be able to connect via a webclient and also via normal xmpp clients.
So here are my questions:
About the Rosters: I want to have the users from the friends list listed in the users contact list. I know that this can be done with rosters. But how can I implement this on a simple and stable way? Is there a good Server implementation that can get the users roster out of a sql database like pgsql?
What happens on the client when the roster datas are beeing changed while the user is logged in on the xmpp server?
Can I group the users that are listed in the roster of a user?
Which XMPP server project would you recommend for that kind of project?
Thanks for your help in advance!
most existing XMPP servers support all popular DBRMs. So this should be no problem.
probably nothing when you make the changes directly do the database. So have to find a server where you can initiate a roster push to all connected clients. See also the XMPP RFCs for roster updates.
yes, roster groups are a core feature of XMPP.
You can find a list of XMPP servers here: http://xmpp.org/xmpp-software/servers/ You have to check which servers support pgsql and allow you to update the roster and initiate the roster pushes to connected resources.

xmpp/jabber for chat for dating site?

we're in the process of adding text chat to our dating site and I'm considering using xmpp - specifically ejabberd on the server side, and we will be implementing an ajax client.
i'd like to hear from someone with good xmpp experience - is it architecturally suitable for chat on a dating site ? in chat on a dating site anybody can chat one-on-one with anybody - they don't have to be on your 'friends' list. Also we do not want a chat room - only one-on-one chat.
Or is xmpp more suitable for the model where someone has to add you to their friends list before you can with them ?
thanks in advance.
XMPP should work fine for you. Ejabberd, depending on the number of concurrent users you have, should be a fine starting point. Consider using a BOSH library like Strophe.js in your HTML client. If you use that library, you'll want a copy of Professional XMPP Programming with JavaScript and jQuery, which has examples of all of the code you'll need.
You do NOT need to have presence subscriptions in place to send chat messages between users, except in specific server implementations like GoogleTalk. Reducing the number of presence subscriptions will also drastically increase the number of users you can handle concurrently.