I'm using Jitsi on client side and ejabberd on server.
It seems that the chat sessions are specific to clients, i.e. if I'm logged in to the same account from 2 different clients, there will be 2 separate sessions, and one can't see what's happening in another.
Is it possible to share the sessions for the same account on all clients? Like Skype or GTalk.
If yes, is it a server configuration or client?
Thank you.
I think what you're looking for is XEP-0280 Message Carbons. Basically the server takes care of relaying the chat to all of your online resources so that you have the same chat session across all devices.
You even get chatstates from all of your other resources so you can infer whether or not you should show an unread IM notification to the user on your resource or not. You'll need client and server support for this, and it looks like ejabberd has implemented it via this module.
Related
Recently started at a new small company that has the following infrastructure:
Private XMPP Openfire server that hosts #chat..com
Google Apps for email, chat, docs, etc. with account of #.com
The company uses the private/internal chat server heavily for communication. However that requires me to install and run a client on my machine like Adium/Psi and then chat history is stored locally etc.
Since getting the entire company to move away from their beloved internal chat server and use gtalk that comes built-in with google apps is not an option, the hope was to register the #chat..com account with gtalk and then handle all communication through gtalk similar to what folks have done with AIM, Facebook, and other transports. Benefit would be the following:
All chat history stored server side on gtalk side and serchable
Other people in the company do not need to change behavior
Android phone that is already sync'd with Google services will not be able to leverage the chats without the need to install another XMPP client.
No need to have a thick client installed on the desktop/laptop
I have researched the XMPP transports and tried to the registering but they do not seem to cover my situation. I have investigated two routes thus far with no luck:
Transport plugin for Openfire
Use public transport at http://jabberd.eu
Guidance and/or experience from someone who has accomplished this would be appreciated.
I've used Spectrum (v1 and v2) to connect Openfire to Gmail and Facebook. It shows up in the users' clients as a discoverable service. It requires that a remote roster plugin be added to Openfire and that Spectrum be run on the same box as Openfire.
In short, it acts similar to a web proxy. Your users don't have to change their account on your system but to Gtalk users, your users appear to be other Gtalk users. Any of your users who access Gtalk will be using their own Gtalk authentication so you don't need to maintain any extra authentication schemes.
Take a look at it at http://spectrum.im. The remote roster plugin for Openfire is attached to the bottom of the first message in http://community.igniterealtime.org/thread/46580 (it's filename is "gojara.jar").
I'm still not quite sure what XMPP is. However I understand it is a protocol which drives many IM services such as FB and GTalk.
What I'm asking is, is it possible for FB accounts to chat to other XMPP accounts (e.g. GTalk) ? Like #hotmail.com emails can email #gmail.com (decentralized) rather than only hotmail.com to hotmail.com etc.
Thanks
Sadly not. At least currently. Facebook does not federate, meaning it does not make or accept connections to or from other XMPP servers.
Of historical note is the fact that Google did not originally federate gmail.com. They enabled this 6 months after they launched Google Talk. There's hope for Facebook yet. Maybe.
Facebook does not provide an XMPP server, just an XMPP API, so it's not possible to have all the operations available at a XMPP server.
As you can see from this link
Facebook Chat should be compatible with every XMPP client, but is not
a full XMPP server.
XMPP allows users to connect to the server from multiple clients simultaneously, using the same account. I built an application that does this but if the desktop client is enabled, I do not want the users to be able to connect using a mobile client. This is for a game and being connected to both causes problems.
So what I'm wondering is:
Is it possible to detect if there are other clients connected using the same account. If I can check for other clients, I can auto logout the user.
#Flow was on the right track. If all of your client instances use the same resource, in most servers, the later-connecting client will replace the older session. The older session will get a conflict stream error, and be disconnected. You MUST be careful not to auto-reconnect with the older client, or you will have written the "dueling resources" bug.
If you had control over your server, you have a chance at configuring it to allow a maximum of one resource for a given user, in which case the newer connection will fail with a conflict error, but you'll have worse user interface problems if you head down that path; there will be no way to get the second client logged in, even if you wanted to.
Finally, all resources for a given user are subscribed to that user's presence. As long as your client sends presence in:
<presence/>
you will receive presence from each of your other devices:
<presence to='user#example.com/resource1' from='user#example.com/resource2'/>
<presence to='user#example.com/resource1' from='user#example.com/resource3'/>
<presence to='user#example.com/resource1' from='user#example.com/resource4'/>
You could use this to decide which client is current, perhaps by adding an extension to the presence like XEP-0115.
Give the desktop and mobile client a fixed but different resource string. If the mobile client logs in, it can detect the presence of the desktop client by looking up the presence/availability of the resource of the desktop client and vice versa.
Then you only need to implement an custom XMPP ad-hoc command (XEP-0050) that tells the conflicting resource to log out.
It would be the servers responsibility: to reject a login from a client that is not accepted. I don't know if servers are able to blacklist xmpp clients but, in case you use openfire, you should be able to write an extension.
I am writing a chat support application that connects to an XMPP server using the SASL Anonymous mechanism. When a user opens my website in their browser, using Socket.IO and NodeJS the server will initiate the anonymous connection with my XMPP server.
This is all working fine. I can connect and communicate with the browser, and it is very cool.
The support team connects to the server using Pidgin. I'd like to be able to display to the browser when the support techs are typing in Pidgin. I set up chat state notifications to work with the browser using AJAX and such, however I am having issues with Pidgin/Adium. Everything seems to work perfectly when I connect from iChat. I get 'active' and 'composing' chat states when the tech is typing. For some reason, however, both Pidgin and Adium are not sending these chat states to the browser client. I've made sure that the proper setting is enabled, as the chat states are being sent between two Pidgin users.
I read something about sending a stanza to report which features a client supports, but the Pidgin client never attempts to request this from the browser.
What am I missing here?
EDIT: I guess I should add that the anonymous browser client is initiating the chat with the Pidgin user, which may be part of the problem here.
Does your client implement XEP-0115, and claim support for the http://jabber.org/protocol/chatstates feature, as specified in section 4 of XEP-0085?
Once you implement that, you'll merely need to deal with libpurple's bugginess.
I have developed MSN, Yahoo and Facebook Instant Messaging using ejabberd, strophe and transports. Every time when legacy user register him self with his credentials to transport, he has to authorize bunch of subscribe requests. Is it possible to avoid this process. I am wondering how meebo adding contacts to respective buddy lists without asking any subscribe requests.
Thanks,
Sathi
I imagine Meebo automatically confirms the subscription requests without the user knowing, since they can (correctly) infer this is the user's intent when interfacing with a social network that does not have asynchronous connections.
Just have your own code automatically respond to ask='subscribe' requests from users behind the gateway to achieve the same thing.