Why use XMPP: native clients vs generic IM alternatives

XMPP, the eXtensible Messaging and Presence Protocol (translation: open IM) rocks. It has a rich feature set. It's well designed. And as a bit of a security nut I especially like that it supports strong encryption and uses a decentralized, federated protocol like e-mail. Anyone can install their own Jabber server (like TurnKey ejabberd). That way private conversations within your domain never leave the security of a server under your direct control. Just like e-mail.

XMPP is actually pretty popular, but most people using it probably don't even realize that they do. They just log into XMPP servers with a multi-protocol client such as Pidgin that doesn't have full support for the XMPP protocol. Just enough to get by with the chat basics.

The alternative is to use a native XMPP client. One that focuses on Jabber. A couple of the best native Jabber clients I've tried are Gajim (implemented in the PyGTK framework) and Psi (implemented in Qt). Both have a similar feature set and are pretty good. I like Gajim a bit better because of how it implements message notification - as unobtrusive corner pop-ups, ala Thunderbird ReminderFox.

Full support for Jabber provides such benefits as:

 

  • improved ability to control administrate MUC rooms

    • silence/kick/ban users (like in IRC)
    • change their privilege levels
    • change the configuration of a room on the fly (after it has been created)
  • ability to administrate your Jabber server in-band (from the client) of servers you control. - add/remove users - change passwords - broadcast announcements (everyone connected to the server receives)

    (better usability compared with the web interface)

  • change your password even if you don't have administration privileges

  • ability to discover services/transports

PS: Google Talk used to be based on XMPP until Google did an evil thing and announced it was abandoning open standards for instant messaging. Yikes. Let's hope they don't do that one day with Gmail.

 

You can get future posts delivered by email or good old-fashioned RSS.
TurnKey also has a presence on Google+, Twitter and Facebook.

Comments

Andrea Celledoni's picture

hello Liraz,
my first step in xmpp was in 2011 with a turnkey ejabberd virtual machine and after some time and fildtest I have chosen, the jitsi client (www.jitsi.org) after that,
 I start to use jitsi video bridge for make a multi video conference (installed inside of turnkey ejabberd ) now I have a little network with more than 60 of my customers (only the fidelized ...)
I think that the ejabberd work fine with chat but we have some problems with multi video conference (the latency is too high in our internet/network)  and other virtual machine that I use (owncloud) seems to prefer to use prosody as xmpp server
https://apps.owncloud.com/content/show.php/JavaScript+XMPP+Chat?content=...
in the next step I will permit the connection from the web browser via webrtc. jitsi use jitsi-meet that is webrtc client, but I see that can work only with the Prosody server
https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md .
In my next steps I will start to use xmpp protocol in social neworking and I hope to monitoring via xmpp my home via openhab software http://www.openhab.org/
please tell me which is your upgrade plan of turnkey xmmp virtualmachine
greetings
Andrea Celledoni

Jeremy Davis's picture

Hopefully Liraz will post back to you but he is really busy so it may not be soon...

Regardless, thanks for posting. You raise some interesting points.

jitsi looks really cool! Your experience/comment with regards to eJabberd and latency is interesting. Theoretically eJabberd and Prosody should be equally effected by network latency; however after a little research I note that it seems Prosody supports some compression that perhaps eJabberd doesn't? (which is probably irrelevant for text, useful for speech and would make huge differences for video!) Also it seems that Prosody it less resource intensive so if resources are limited then that might also be a factor.

I had a look at your ownCloud link and other than reference to fixing Prosody bugs in the changelog I didn't get a preference for that over any other XMPP (but I'm happy to take your word for it...)

From what I could see I'm not sure that jitsi-meet requires Prosody, just that by default it recommends it because it's light weight and easy to configure (OOTB it is pretty much ready to go). After a bit of googling I gather that apparently if you turn off user authentication in eJabberd it should work with jitsi-meet (but I didn't test or anything).

Regardless, it seems that although eJabberd is still (by far) the market leading XMPP server, Prosody is a low resource free software alternative which is under heavy development with a vibrant community. Also the fact that it's written in a relatively friendly language - lua (Prosody) vs erlang (eJabberd) probably helps get new developers on board. It could be worthy of an appliance too? (Alongside the eJabberd one, rather than instead of...)

Xander Dumaine's picture

This idea around latency with regards to video is not actually true. Neither Prosody nor eJabberd actually touch the video itself, they just act as signaling servers (jingle) and video is routed directly between peers (or between peers with jitsi in the middle). Any compression that Prosody does wouldn't affect video at all.

andrea celledoni's picture

hello, Xander Dumaine

please describe you fildtests.

You know

https://github.com/jitsi/jitsi-meet/blob/master/doc/quick-install.md

?

 

 

Jabber-Server.de Admin's picture

Did you tried Spark? It's a native XMPP Client and as cross-platform available. It comes with OTR support out of the box and can be added with video and voip calling functionallity.

You can get it over here: http://www.jabber-server.de/register/#download-spark

The OTR functionallity in action can be seen here in a short video i made: http://youtu.be/xEAmLnXo7e4

Andrea Celledoni's picture

hello  
 
I tryed to test some xmpp client I have seen spark and red5 server,  but as I writed in my other post now my little network is working fine, my focus is integrate other services in the cloud server
as is explained in http://www.opentelecoms.org/federated-voip .
now I try to balancing security and performance of the gateway, please tell me waht do you think about and if you have experince in federated voip xmpp sip.

 

Pages

Post new comment