What instant messaging system would you use, to extend a website with a secure 1:1 chat with their customer services representative? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.

Closed 7 years ago.

Improve this question

I need to implement a chat system for a website, so that customers of the can talk to their customer services representatives one-on-one online over the website.

So wha开发者_StackOverflowt I need is a system which does:

• Shows a list of representatives in the browser, with status indicating if they're online or not
• Allows the user to open a chat with a representative; probably the user is presented with a new screen or pop-up where they can chat.
• The website is HTTP but the chat needs to be HTTPS therefore I guess having an overlay on the exitsing screen, to do the chat, e.g. like Facebook does it, isn't really plausible
• The manager needs some application or website where they can log on, and chat to their customers.
• Obviously I would prefer an open-source solution if possible.
• We are using Java for most things but it doesn't really matter, I wouldn't mind installing a system in another technology if necessary.

What I've considered so far is:

• Using Jabber/XMPP, communicating over HTTPS using an AJAX client; there are plenty out there, I'm not sure which is best, perhaps JWChat (screenshot). This would have the advantage that a bank manager could use a desktop client (e.g. Windows client) if they preferred, that might have nicer UI if they're using it all day.
• "irc" is also an open protocol, there are no doubt many client implementations available; however I assume there's no way to comply with the security requirement that HTTPS (or perhaps some other secure protocol) is used.
• I do a lot of GWT programming and in the book "GWT Applications" there is a simple instant messaging client implementation (demo). Perhaps I could just roll my own in a similar style?

My questions:

• What approaches have I not considered?
• What approach would you take? e.g. software which you've used which worked for you?
• If you were to e.g. use Jabber/XMPP (without further information, I'm sort of leaning to that solution..) which AJAX client would you consider?

---

One option that you've missed is something based on SIP. SIP and XMPP have always been considered to overlap somewhat, although XMPP seems to have won out for the specific case of instant messaging. I don't have any knowledge of IM over SIP.

I would go with XMPP because:

• Server implementations are mature, which means that you can change the server later if you need to without affecting the rest of your infrastructure.

• There are lots of ready-made clients, including ones suitable for your bank's customers (AJAX) and ones suitable for your bank managers (desktop).

• IM over XMPP is common. The most common case for SIP is VoIP. If you try and get help with IM over SIP, most SIP experts will tend to know far more about voice than IM. If you try and get help with IM over XMPP, that's exactly what XMPP experts deal with all the time. The same applies to documentation: SIP documentation will tend to be geared around VoIP.

• Using a solution that doesn't support XMPP or SIP is a dead end in terms of development, in my opinion. Even Google and Facebook are using XMPP now. XMPP appears to be the future-proof option now.

• IRC is a many-to-many chat mechanism. There is DCC but that is mainly around establishing a one-to-one channel for communication. I think that if you did implement something based on IRC, you would spend a lot of your time pulling out the many-to-many function where you don't want it, and there won't be much else left, since you'd also have to replace the DCC implementation with something to go down AJAX/XmlHttpRequest/WebSockets instead.

• If you ended up customising things more and more, XMPP is well-engineered, well-specified and a good base to start from. You could incrementally replace the web client, the desktop client and the server without disruption or headache.

Some possible caveats:

• XMPP servers want to talk to other ones, since the protocol is designed to be federated. You need to make absolutely sure that this won't happen. XMPP normally talks on 5222 for client->server and 5269 for server<->server, but SRV is also used.

• The same goes for whichever client you choose. You may need to cut it down to make sure that users cannot use functions that are common to more general use, such as adding and deleting users from the roster (and worse, outsiders on eg. GTalk managing to confuse and perhaps phish your customers).

The two biggest issues that I think you might have with XMPP are:

1. Managing users and rosters on the XMPP server, since they are mostly designed for general use and not a sandboxed environment. The server will tend to expect and allow the clients to register, set passwords etc, whereas you presumably want to both prevent this from happening and manage everything yourself.

2. Cutting out all the extra features that could cause problems. You presumably don't want your customers speaking to each other, transferring files about etc.

I have set up and maintained a private multi-site, multi-server, private XMPP installation spanning a number of connected customers, back in about 2002. The main things I had to do were:

1. Getting a server implementation cut down as mentioned above. I used jabberd 1.x, which used XML files for configuration. I integrated it with our user database by supplying roster XML files already pre-populated. Users could in theory mess with their rosters, but they would get overwritten by the server. In practice this didn't happen because the client software prevented it. You will probably need to go a step further than this, but I believe there are servers flexible enough to allow it now.

2. Getting a client implementation that could be automatically pre-configured and not messed with. I selected and patched a specific client (Psi) to add a "lockdown" mode which could be used to remove all configuration-related UI elements, including roster management options. Configuration was instead automatically done by the server. Users would then have something simple that they did not have to configure and that could not go wrong. Something like this might work for your bank managers - it will save a lot on support.

---

This is a lot later, and some newer technologies have emerged, namely WebRTC.

It allows audio/video calls, data transfert in a P2P fashion, while using native browser APIs.