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/
Related
We have an enterprise installation of QuickBlox (which implements XMPP), and would like to create mirrored accounts for all of our users on our QuickBlox server install. We also want to sync the networks our system's users have created using relationships (eg, "client and provider") that have been built on our system.
In a nutshell, we want to export whitelists that limit chat "opponents" to only those users with whom each of our users already have relationships. If User1 has an existing relationship in our system with User2 and User3 but not User4 through User40, we want to be able to use the QuickBlox API to enforce that within chat by creating a whitelist through the QuickBlox API.
EDIT: We can't use an "honor system" whitelist. That is, the enforcement must be server-side using a method the client cannot circumvent. There must be a hard, unavoidable block between users for privacy concerns.
Use case:
A QuickBlox (or XMPP) server has User1 through User40, inclusive.
User1's whitelist is comprised of [User2, User3] only.
If User1 attempts to contact User15, we want QuickBlox/XMPP to note that User15 is not on User1's whitelist and block that communication as if User1 had bidirectionally blocked that user.
Privacy lists, aka blacklists
I have found places in QB's docs that refer to the XMPP specification docs, and have found the concept of privacy lists, which seem to operate as blacklists:
https://quickblox.com/developers/Web_XMPP_Chat_Sample#Privacy_lists
https://xmpp.org/extensions/xep-0016.html#protocol-syntax
These only provide two styles of blacklist privacy:
You can choose a type of blocked logic (Privacy List). There are 2
types:
Block in one way. You are blocked, but you can write to
blocked user.
Block in two ways. You are blocked and you also can't
write to blocked user.
Server Whitelist (dialog-level, not user)
I've also found documentation on whitelists for servers, which appear to operate at a dialog/jid, not user, level:
https://xmpp.org/extensions/xep-0133.html#edit-whitelist
An entity added to a whitelist MAY be a JID of any form as specified in RFC 6120... a whitelist may prevent inbound communications, outbound communications, or both...
Rosters -- "presence" detail only?
There are also rosters, which are close to whitelists, but they do not seem in my testing to restrict communication between any two users that might not be on each other's roster.
https://quickblox.com/developers/Web_XMPP_Chat_Sample#Get_the_roster
That is to say, I haven't set up a roster in my testing application, and users are able to create group and 1-on-1 chat dialogs in spite of not having explicitly accepted any roster requests. In the Android docs, I found the following on rosters: "[A roster] is the collection of users a person receives presence updates for." That's not blocking in any way outside of presence alerts, I don't believe.
Question
Is there a suggested way to create a pessimistic whitelist for each user, which only contain those users with whom communication is allowed? Or are we forced to create and maintain "inverse blacklists", where we automate the creation of privacy lists for every new user blocking every other user and then use the API to remove those with which each user should be able to communicate?
If we do have to use "inverse blacklists", is there a way to have a default blacklist apply to every new user that initially blocks communication with every other user already in our QuickBlox system?
(Again, we can't use "honor system" lists. If the client must request a whitelist to be active before it can be used, can freely discover and then change active whitelists, or if the client can decline to use a list, that's not secure enough.)
XMPP Clients
XMPP clients will need a way to ask another clients if they support receiving pushes via a relay. Since pushes can be sent from anywhere, clients will also be able to send pushes directly to other clients through the relay as long as they have their friend’s whitelist token. They will also need to respond to XMPP server inquiries for whitelist tokens to allow pushes to be sent by the server if a message is sent by a client not supporting direct push.
XMPP Servers
XMPP servers can ask their connected clients if they support push relays and, if so, forward messages they receive to the push relay server when the client is offline. This will require the XMPP server to obtain a whitelist token from the user as well.
Help:see this link
If we are talking about XMPP protocol - there is an ability to block any communications from/to (see example 48)
So, by default, you can set it for each user for example.
Then, if we need to allow to communicate with someone specific,
then you can add this user to your privacy list with action=allow and order greater than 'full block'. Here is actually a good example of whitelist implementation via Privacy Lists, see example 8:
and (3) 'special', which allows communications only with three
specific entities.
I am working on the chat application.
I want to implement the group user chat and I have successfully done that.
Now I want toad the functionality by which user can leave the group. I found leave the group but it seems like it's just making user unavailable but not removing user from the member list.
Is there any way by which user remove himself from the member list?
I have read the xep 0045 for it, in that there is a topic for existing the room which seems make user unavailable but not removing from member list.
http://xmpp.org/extensions/xep-0045.html#exit
If anyone has any idea how to do this please share it.
Leaving a room in XMPP (0045) is accomplished by sending an unavailable presence to that room (see XMPPRoom.leaveRoom() in the XMPPFramework) - that should remove them from the occupants of that room (we do this with our app regularly).
"Members list" - is a MUC feature for moderator use cases, it is not related to user. Just leave room as described in XEP, you no need to modify members list. In fact, you no need to add user in this list too, simple chat application should only tracks <presence> stanzas from and to room JID.
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.
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.
I am working on a social network that should allow members to chat with visitors on the site. The concept is simple.
Users who have registered signup get their own account with rosters
When a visitor comes to the home page of the social network, he can see some of the online members of the community
Now he should be able to initiate a chat with them, by clicking on their name.
I have already got members to chat with their roster mates. My question is, how can I get an anonymous user to chat with a member and exchange presence info with him?
I have successfully managed to create anonymous accounts, members accounts and even send messages from an anonymous user to other members. But I cant get presence information from anonymous-user to member or vice versa?
BTW, the chat is JS based.
You're trying to break the XMPP model. Presence is an opt-in permission based system. You ask me if you can see my presence, I say yes. Generally my client will then automatically ask you if I can see your presence, and your client says yes. That's what the roster is -- yes's and no's to presence subscription requests.
You can make chat rooms (MUC, multi user chat) that are anonymous, as well as do presence in them. It's not a roster, though. It's the closest to what you're describing without going into crazy-land with pubsub, and I don't know if you could even bend that tool far enough to have anonymous roster entries.