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.
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.
I'm creating a chatroom website were each user can create a room and add his friends to that room and then start chatting!:D I'm using XMPP as the tool for this site with ejabberd server and smack API as client for room configuration! as you've already understood rooms are member only but I'm looking for a way to let each user see all rooms that she is a member of!
is it possible with xmpp protocol(to get all rooms that I'm member of)?how?
Does making the rooms public solve the problem? BTW how can I do it with smack API?
or better say, how can I choose to set a room public or hidden
thanks in advance
No, it is not possible in XMPP. This has been asked before, see: Is there a way to determine which Mulit User Conferences (MUC) a user has joined?
You could however keep track of these rooms yourself in a separate data store each time an user would enter (and/or leave) the room, but this is outside the scope of XMPP as mentioned earlier.
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.
I hope this is allowed but I have a number of questions regarding Facebook Connect, I'm quite unsure on how I should approach implementing it.
I am working on a live music type service and currently have user registration, etc. If I were to implement Facebook Connect alongside this, would I still be able to email the Facebook Connect users as if they were on my database?
Also, would it instead be possible to let users who have Facebook "link" their accounts once registered so I am able to give them the benefits of sharing via Facebook and inviting friends while still having an actual registered user on my system.
I have tried to read up answers to the above questions but what I've found is quite ambiguous.
Thanks, look forward to your views.
Facebook's documentation process is very poor, so don't feel bad about having a hard time getting started. Their wiki-style approach to documentation without any real official documents tends to leave the "process flow" tough to grasp, and requires piecing together parts of a bunch of randomly scattered docs.
Facebook has an obligation to protect privacy, so they never make a user's actual email address available to application developers, through Connect or normal applications. They do have a proxied email system in place that you can use, however, you must get explicit permission from a user in order to email them. There's a decent document on proxied email here. You can get permission by prompting for it; there's several methods for doing so linked in that document.
In regards to linking Facebook and local accounts, this would definitely be the way to go. Once a Connect user logs in, you want to store that fact for that user so you can provide the Facebook-specific functionality. I would simply create a normal user account in the database for every new Connect user that came by, with it's own local id, so that you don't have to do special handling of two different types of user accounts all over the site. That being said, the account would obviously have to be marked as a Facebook user's account (I use an externalId column in my users table), and any part of the site that relied on information you might otherwise have locally would have to handle the Facebook aspect properly (such as using proxied email instead of normal email).
For existing users, you could arrange an "account link" by having a process whereby they log into FB Connect after they've logged into the site already, and you could detect that and simply add their FB id to your users table. After that, they could log in through Connect in the future, or through your normal process. I've never done this, but it should be possible.
If you write the account handling code generically enough, your site will be able to function well no matter what kind of user you throw at it.