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.
Related
We are developing a consumer hardware product. Each device is registered on a central webserver and the owner also have a user account to which the device is linked. The owner may also choose to share the device with other users.
Now, to solve the problem of getting through firewalls etc we are using XMPP: the user access his/her devices using an iOS/Android app. The app connects to the XMPP-server and so does the hardware devices. So the app can access the devices by sending custom XMPP stanzas.
Currently the device and the mobile app use the same JID, so the device will allow messages only from the same bare JID as itself uses. To allow for sharing devices we are planning to use the roster instead: the device will get its own JID ("hw381983829#thexmppserver.com") and will accept stanzas from all JID's in its roster.
The problem I'm having is that the users, devices and device-sharing data are stored on the webserver. I would like to use this same information on the XMPP-server: all users and devices on the webserver are allowed to login to XMPP and the roster of a device is the same as the users that may access it. This information can be accessed through a JSON API.
One way would be to mirror changes as they happen, but I don't like that idea since there are too many steps that could go wrong.
The best solution I can think of is to let the XMPP server use the JSON API instead of its builtin database. It would be read-only, but that is not a problem since all registration and sharing should be done on the webserver.
Any ideas on how to proceed? The functionality described above is more or less all that we need: we don't need S2S, offline messages, etc. We are currently using Ejabberd, but Prosody or Openfire are perhaps better alternatives?
For authentication, it looks like this ejabberd contribution does exactly what you need:
https://github.com/processone/ejabberd-contrib/tree/master/ejabberd_auth_http
For roster, it is easy to write a custom roster module that will be hitting your HTTP backend instead of query the database thanks to ejabberd API.
You can have a look at mod_roster as a guide to implement the methods: https://github.com/processone/ejabberd/blob/master/src/mod_roster.erl
I'm creating (yet another) mobile chat app, using Smack and ejabberd. I'm trying to ascertain the best way to implement user avatars for use in multi-user chat rooms, and also of course for roster members. Looking at possible solutions, I can see:
XEP-0008 IQ based avatars - avatars are limited to 64 by 64 pixels, too small.
XEP-0153 vCard based avatars - Easy to implement for both users in the roster and MUC rooms, however (a) sources such as this seem to indicate that one's own vcard needs to be downloaded on every login (is this strictly true? I can't see this in the specs), and (b) should be less than 96 by 96 pixels (still pretty small)
XEP-0084 User Avatar based on Personal Eventing Protocol - I'm not clear how I can retrieve avatars for all users in a multi-user chat room based on this protocol. After joining the chat room, I would need to subscribe to the metadata node of all users, and any subsequently joining users? And also unsubscribe when they leave the room? I figure this would be pretty ugly and clumsy to implement.
Can someone kindly point me in the right direction, or indicate where I may have misunderstood? Thanks.
I guess the best way to address this issue may be to store/load the images Out of band via a HTTP server. Images could be stored with a filename such as "username_imagehash.xxx". For users not in one's roster (eg strangers in a multi-user chat), we pull their avatar via a URI retrieved from their vCard PHOTO field. Each time a stranger is re/encountered, we reload their vCard, and can identify the need to redownload their photo via a change in the URI in the vCard.
Once the user is added to one's roster, we subscribe to their avatar updates via XEP-0084, publishing the same URI (see example 4. in XEP-0084).
I think this addresses all requirements, I will find out once I've implemented. I can understand that it is not done this way in standard XMPP clients as it depends on an HTTP server separate to the XMPP service (and need to handle HTTP server security - user authorization/authentication).
Feedback welcome!
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.
And in that case what's the name of the permission/method/function etc.
I believe user-to-user is possible (At least I have seen for chat in OmgPop)
For application to user,
You can only read for now using the /inbox endpoint.
You will need the read_mailbox permission.
You can read more from the 2009 post.
While we currently don't allow applications to send messages through this API, we're always thinking about new functionality to offer through Facebook Platform.
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.