While primarily an XMPP library that preserves connection between page switches, Z-XMPP also includes an ugly user interface component for instant messaging. It appears as a bar on the bottom of the screen.
WARNING: Use is not recommended: There are other, immensely better UI and client libraries today. The author is open to admit he barely knew what he was doing back in 2010. In 2019, the author would recommend projects such as Strophe.js for the in-browser client library, and Converse.js for the full client UI.
It's an XMPP
(also known as Jabber) client.
state. This is done so that making use of the latest innovations in HTML5 such
sessionStorage is not only possible, but is recommended. By
serializing the state using
sessionStorage and restoring it upon
page load, Z-XMPP can persist the XMPP stream between page switches. This is
similar to what Facebook Chat seems like to users of Facebook: clicking on a
link does not restart the chat session, and to other people, the user does
not appear to be logging in and out. At the same time, web developer is not
required to create the entire web site using AJAX; backing web site can be
written in any way desired, as long as Z-XMPP code is included.
So the biggest specialty of this client compared to its older brethren is its ability to persist the connection between page switches.
Most of the client is the communications code, as well as maintaining relevant state. This is intentionally separated from the (currently extremely rudimentary and poorly written) UI. This means you can either use it as a client, or as a library, or even both.
Client is currently hosted on http://bitbucket.org/ivucica/zxmpp/. See instructions on BitBucket to see how to get the code using Mercurial, or just download an archive of the current snapshot of the code from BitBucket's web interface.
To contribute to the development effort:
A suggestion: Someone could rewrite the bar interface. JQuery ninjas are especially welcome to contribute (although anything decently written will be accepted). You don't need to worry about networking; as long as you provide me with a nice&simple API to: 1. add users to roster, 2. remove users to roster, 3. update users in roster, 4. update user's status in roster, 5. display a message from a user, 6. register a callback to send a message... well, that's it! The UI should be bar-based, since that is most useful for most people; otherwise, the field is yours!
Grouping users would also be appreciated, but is not required.
XMLHttpRequest-based connections, in accordance to the
and XEP-0206. In short,
you need a BOSH connection manager (either specialized such as
Punjab or built in, such as those
in Prosody or
ejabberd), which exposes a HTTP-based
interface, to which BOSH-based clients such as Z-XMPP can communicate to.
User interface is separately implemented, and it needs to be explicitly linked
to Z-XMPP when Z-XMPP and Z-XMPP UI are instantiated. Same with serialization:
you need to explicitly serialize and deserialize Z-XMPP on page unload and
page load. This allows you to develop your own UI, to intercept
<message> stanzas, et cetera. Currently, a low number of
callbacks is exposed, but if there is sufficient interest or if it proves
fun enough, there are plans to develop Prosody-like plugin API allowing you
to register callback to an arbitrary tree node.
Take a look at
demo.php in the repository in order to see how to:
To get Facebook Chat-like functionality (that is, automatically log user in when he visits your web site) you should use a bit of your own ingenuity. For my current setup, keywords are: ejabberd, external authentication, one-shot authentication key (to avoid echo-ing plaintext password in HTML sent to the user).
Before you implement Z-XMPP on your latest cool web project, stop. Please note that Z-XMPP is by no means designed to be super-secure. Here is a short list of the current major issues if you're not super careful.
sessionStorage(or if you choose to implement serialization using cookies) might be accessible to third party sites on your domain. There might be too much data stored in browser's memory as well.
echouser's password. When implementing autologin into Z-XMPP based on user's credentials for your web site, resist the temptation to just
echouser's permanent credentials onto the web site. This means someone could dig the cache and take a look at what password the user uses. Instead, upon page access, dynamically create a one shot authentication key which will be accessible only by the external authentication library of the XMPP server. Make this token time limited.
Instead of writing a detailed setup guide, I'll give you just a few tips:
.htaccessfor apache is included! It requires enabled
mod_rewrite(which conflicts with
.htaccessmentioned above is in there
demo.phpto see how to integrate Z-XMPP with your web site
firstname.lastname@example.org. This'll stimulate further development and make my heart all warm and fuzzy.
You need to implement your own Facebook authentication, either using Facebook's JS API or some other method. Then just pass the application ID as username, and access token as password. Also, in configuration, set
fb-auth-enabled to a truthful value. This is needed so you can still use other SASL methods when connecting to a server supporting
My personal want-to-do minilist, in order of necessity:
Currently LGPLv2. See LICENSE for details, and in case something changed.