6 ms·

Why XMPP Will Be Huge Very Soon

52 points by mbleigh 18y ago

nihilocrat 18y ago
He's missing the main reasons why my company is going forward with a Jabber server: privacy and reliability. We are a geographically distributed company that uses ICQ for a whole lot of communication, so when it goes down for any reason, work just about halts. Also, we routinely discuss very sensitive things (but we call each other if we need to discuss root passwords), so a dedicated eavesdropper could learn more than we'd like him or her to.
- josefresco 18y ago
  Pidgin + OTR FTW
  - jerf 18y ago
    Solves the encryption problem, but doesn't solve the reliability problem. Also, if your company needs to be able to log the IMs for compliance reasons, that doesn't solve that either. (Disclaimer: I work for a company that builds IM servers for companies. But... the above isn't exactly controversial.)
    - josefresco 18y ago
      You can still log with OTR, and if you use AOL/ICQ/MSN/Gtalk etc. there will always be at least one network still kicking.
      - there 18y ago
        unless your corporate network's internet connection is down...
        josefresco 18y ago
        Then you have bigger problems. I'd start with a reliable net connection if you want to do business online.
        there 18y ago
        shit happens. being able to contact someone when it does is important. i used to work for an isp and we had a private irc server that was very valuable in the case of outages when we needed to broadcast information to other departments. if i had to deploy it again now i'd choose an xmpp server, but either way, relying on an off-network communication server is not a good idea for a variety of reasons.
- axod 18y ago
  Why not just an irc server, with SSL and passwords etc?
axod 18y ago
Funny, I heard the same argument years ago.
daleharvey 18y ago
I think thats missing a big reason, google adopted it. I have seen a resurgence of applications built on xmpp and instant messaging in general, I dont think a lot of people will know they are using xmpp, but it will be lurking in the back
mdasen 18y ago
So, I do think that XMPP will become a much bigger force given the (anecdotal) rate that post-college students replace their college email with Gmail (and get Google Talk with it). However, XMPP can't just rest. It really needs to get Jingle (their VoIP/video protocol) finished and approved and adopted. With more people looking to use voice and video online, they can't be left behind because of lack of features. With Google driving some adoption and (hopefully) smaller IM networks seeing that XMPP would be in their interests (since it would help them overcome a lack of users), XMPP could see decent enough growth. However, if other networks have desired features that XMPP doesn't offer, the interoperability argument is countered by the lacking of things users want.
trezor 18y ago
Unless I'm missing something totally obvious, many of these reasons might as well be said for SIP.
bemmu 18y ago
When I need to do something realtime, I connect users to my IRC server. Writing a client for IRC in Flash is very easy, I haven't tried with Javascript, I imagine you would use a keepalive connection somehow. Am I missing something by not using XMPP?
- axod 18y ago
  >> "Am I missing something by not using XMPP?" You're missing hours of headaches working through over-engineered ridiculously overly complicated horrible XML protocol. Stick with IRC ;)
  - cubedice 18y ago
    I just coded a level file in XML for a game being developed in one of my classes. The same group member who was so adamant about coding the levels in XML had neglected to build an XML creation program. So there we were, trying to wade through > 10,000 lines of XML. I wanted to cry
  - clemesha 18y ago
    FWIW, I've had a different experience with XMPP. Take for example XMPP Multi-User Chat (http://xmpp.org/extensions/xep-0045.html http://xmpp.org/extensions/xep-0045.html) - which outlines a rich set of interactions between occupants of a room - something I'm really glad someone else engineered for me. Plus, take a look at the XML stanzas (in the examples here: http://xmpp.org/extensions/xep-0045.html http://xmpp.org/extensions/xep-0045.html) you are sending to the server, they're really not that big or complicated. Lastly, with BOSH (http://xmpp.org/extensions/xep-0124.html http://xmpp.org/extensions/xep-0124.html) and incredible XMPP Javascript client libs like Strophe (http://code.stanziq.com/strophe/ http://code.stanziq.com/strophe/), the possibilities are pretty exciting for web apps.
    - axod 18y ago
      A quick skim of the Multi-User Chat though... Firstly, it's 9 years old :/ why is everyone still not using it? Secondly, you can immediately tell it's ridiculously over-engineered. <field var='muc#roominfo_occupants' label='Number of occupants'> <value>3</value> </field> Sorry, but you can't really look at that protocol and say it's not ugly and verbose beyond reason. The number of occupants in a room is surely used enough to deserve an encoding of less than 75 characters to specify a number.
l_frequency 18y ago
Anyone know of any good XMPP implementations that lend well to implementing gateways? Preferably in C/C++?
- jerf 18y ago
  Your question is somewhat vague and muddled. Could you clarify what exactly you are asking for? How are you using the term "gateway"?
  - l_frequency 18y ago
    Gateway is as is defined in RFC 3920 Section 2.1 "G1 = A gateway that translates between XMPP and the protocol(s) used on a foreign (non-XMPP) messaging network" I don't think my question was not vague at all. It just might be out of the ordinary. Most people are interested in XMPP client implementations. I want a pre-existing open-source project that would be a good first step towards building an XMPP gateway.
    - jerf 18y ago
      OK, I wanted to make sure that you were indeed asking for that. While you are correct that "gateway" is well-defined, most of the time I see it, it is misused or used vaguely. So, I can help you out. The only library that I know of that is designed specifically for the purpose of implementing gateways is Thrasher Bird: http://developer.berlios.de/projects/thrasher/ http://developer.berlios.de/projects/thrasher/ (git at http://repo.or.cz/w/thrasher.git http://repo.or.cz/w/thrasher.git ). I am the lead developer of that library. While the "sales pitch" is that it wraps libpurple, it is actually designed so that the "gateway" part of the library is separate from the "protocol" part of the library, unlike every other gateway I've seen. It's in Perl, and it's still a bit alpha-ish, but it is also exactly what you are looking for and in active development, so you'll have to decide whether that meets your needs. If you're interested in more information or need help, contact me at jbowers@barracuda.com . Compiling may be a bit of a chore, but I've managed it on a couple of different Linux systems now.
      - 18y ago
deleted 18y ago
[deleted]
thwarted 18y ago
Once I get it working, I love it, but there's two problems I've always had with getting XMPP working from a programming/developing standpoint, both of which kept it from going mainstream sooner: 1) there were very few docs that explain the terms (roster, what a conference server is and why that is different from your regular connect server) in the context of other messaging protocols (AIM, for example). Yeah, I know now that "roster" is the equivalent of the buddy list, except it's not because there are operations that can happen on the roster and it's not complete clear which component maintains the roster and a lot of roster operations can happen asynchronously (due do its distributed nature) even when you're disconnected. None of this was obvious. 2) The docs that did exist, even for abstraction libraries, talked about creating XML stanzas and the XML stream and all the different XML namespaces (none of which were explained well enough to know when you would use 'em) and XML this and XML that. I don't want to write XML, I want to connect to a server and send and receive messages. That it is XML stream based is beside the point--and this was always touted as the reason that XMPP was so awesome, but we all know that it got caught up in the XML hype of the period in which it was conceived. Eventually, libraries started being written that provided the correct level of abstraction for developers rather than protocol designers. Last one I used was Net::Jabber::Bot (cpan), which was okay, but there's still a lot of data extraction from partially cooked XML structures.
bjclark 18y ago
This guy obviously hasn't actually used xmpp in real life. eJabberd does really weird things to us when we throw 300-400k messages at it a day. And this: "XMPP servers, which are essentially make or break an XMPP application, are rapidly maturing beyond instant messaging." Have he ever tried to actually debug ejabberd? Cause it's very painful and time consuming. Now, I'm not bashing xmpp, it's pretty cool, but it's not exactly "the next big thing", IMO. We're actually abandoning it for AMPQ.
- icepick 18y ago
  "eJabberd does really weird things to us". Describe the weird things, please. I'm about to deploy ejabberd for a production site, and I'm interested in your experience.
  - bjclark 18y ago
    Huge processor spikes which we think are caused by too many connections to a single room or user. We're not 100% sure because we can't replicate it in a dev environment and we don't really want to turn on debugging in a production environment, not to mention that debugging mode isn't the most helpful thing ever. If you start it up in "live" mode (ejabberdclt live), we see "Replacing connection..." sometimes, which then throws a "Broken Pipe" error in our rails app. But again, we can't isolate what's happening there.
  - known 18y ago
    XMPP is XML based and need heavy processing power (for e.g. not suitable for mobile platform) whereas AMPQ is a binary protocol. http://www.deepdarc.com/2008/02/14/mobile-xmpp/ http://www.deepdarc.com/2008/02/14/mobile-xmpp/
  - stephenjudkins 18y ago
    Keep in mind that the problems we're having aren't with XMPP, per se, just with ejabberd. Ejabberd worked flawlessly for several months until it started exhibiting some very strange behavior and performance characteristics. We upgraded to a newer version and we suddenly ran into another, different set of strange behaviors. That said, word on the street is that ejabberd is the best implementation of an XMPP server. AMQP supposedly offers better reliability (with RabbitMQ) as well as a whole lot of pretty cool features that Jabber really doesn't.

52 points by mbleigh 18y ago

He's missing the main reasons why my company is going forward with a Jabber server: privacy and reliability. We are a geographically distributed company that uses ICQ for a whole lot of communication, so when it goes down for any reason, work just about halts. Also, we routinely discuss very sensitive things (but we call each other if we need to discuss root passwords), so a dedicated eavesdropper could learn more than we'd like him or her to.

josefresco 18y ago
Pidgin + OTR FTW
- jerf 18y ago
  Solves the encryption problem, but doesn't solve the reliability problem. Also, if your company needs to be able to log the IMs for compliance reasons, that doesn't solve that either. (Disclaimer: I work for a company that builds IM servers for companies. But... the above isn't exactly controversial.)
  - josefresco 18y ago
    You can still log with OTR, and if you use AOL/ICQ/MSN/Gtalk etc. there will always be at least one network still kicking.
    - there 18y ago
      unless your corporate network's internet connection is down...
      - josefresco 18y ago
        Then you have bigger problems. I'd start with a reliable net connection if you want to do business online.
        there 18y ago
        shit happens. being able to contact someone when it does is important. i used to work for an isp and we had a private irc server that was very valuable in the case of outages when we needed to broadcast information to other departments. if i had to deploy it again now i'd choose an xmpp server, but either way, relying on an off-network communication server is not a good idea for a variety of reasons.
axod 18y ago
Why not just an irc server, with SSL and passwords etc?

axod 18y ago

Funny, I heard the same argument years ago.

daleharvey 18y ago

I think thats missing a big reason, google adopted it. I have seen a resurgence of applications built on xmpp and instant messaging in general, I dont think a lot of people will know they are using xmpp, but it will be lurking in the back

mdasen 18y ago

So, I do think that XMPP will become a much bigger force given the (anecdotal) rate that post-college students replace their college email with Gmail (and get Google Talk with it). However, XMPP can't just rest. It really needs to get Jingle (their VoIP/video protocol) finished and approved and adopted. With more people looking to use voice and video online, they can't be left behind because of lack of features. With Google driving some adoption and (hopefully) smaller IM networks seeing that XMPP would be in their interests (since it would help them overcome a lack of users), XMPP could see decent enough growth. However, if other networks have desired features that XMPP doesn't offer, the interoperability argument is countered by the lacking of things users want.

trezor 18y ago

Unless I'm missing something totally obvious, many of these reasons might as well be said for SIP.

bemmu 18y ago

When I need to do something realtime, I connect users to my IRC server. Writing a client for IRC in Flash is very easy, I haven't tried with Javascript, I imagine you would use a keepalive connection somehow. Am I missing something by not using XMPP?

axod 18y ago
>> "Am I missing something by not using XMPP?" You're missing hours of headaches working through over-engineered ridiculously overly complicated horrible XML protocol. Stick with IRC ;)
- cubedice 18y ago
  I just coded a level file in XML for a game being developed in one of my classes. The same group member who was so adamant about coding the levels in XML had neglected to build an XML creation program. So there we were, trying to wade through > 10,000 lines of XML. I wanted to cry
- clemesha 18y ago
  FWIW, I've had a different experience with XMPP. Take for example XMPP Multi-User Chat (http://xmpp.org/extensions/xep-0045.html http://xmpp.org/extensions/xep-0045.html) - which outlines a rich set of interactions between occupants of a room - something I'm really glad someone else engineered for me. Plus, take a look at the XML stanzas (in the examples here: http://xmpp.org/extensions/xep-0045.html http://xmpp.org/extensions/xep-0045.html) you are sending to the server, they're really not that big or complicated. Lastly, with BOSH (http://xmpp.org/extensions/xep-0124.html http://xmpp.org/extensions/xep-0124.html) and incredible XMPP Javascript client libs like Strophe (http://code.stanziq.com/strophe/ http://code.stanziq.com/strophe/), the possibilities are pretty exciting for web apps.
  - axod 18y ago
    A quick skim of the Multi-User Chat though... Firstly, it's 9 years old :/ why is everyone still not using it? Secondly, you can immediately tell it's ridiculously over-engineered. <field var='muc#roominfo_occupants' label='Number of occupants'> <value>3</value> </field> Sorry, but you can't really look at that protocol and say it's not ugly and verbose beyond reason. The number of occupants in a room is surely used enough to deserve an encoding of less than 75 characters to specify a number.

l_frequency 18y ago

Anyone know of any good XMPP implementations that lend well to implementing gateways? Preferably in C/C++?

jerf 18y ago
Your question is somewhat vague and muddled. Could you clarify what exactly you are asking for? How are you using the term "gateway"?
- l_frequency 18y ago
  Gateway is as is defined in RFC 3920 Section 2.1 "G1 = A gateway that translates between XMPP and the protocol(s) used on a foreign (non-XMPP) messaging network" I don't think my question was not vague at all. It just might be out of the ordinary. Most people are interested in XMPP client implementations. I want a pre-existing open-source project that would be a good first step towards building an XMPP gateway.
  - jerf 18y ago
    OK, I wanted to make sure that you were indeed asking for that. While you are correct that "gateway" is well-defined, most of the time I see it, it is misused or used vaguely. So, I can help you out. The only library that I know of that is designed specifically for the purpose of implementing gateways is Thrasher Bird: http://developer.berlios.de/projects/thrasher/ http://developer.berlios.de/projects/thrasher/ (git at http://repo.or.cz/w/thrasher.git http://repo.or.cz/w/thrasher.git ). I am the lead developer of that library. While the "sales pitch" is that it wraps libpurple, it is actually designed so that the "gateway" part of the library is separate from the "protocol" part of the library, unlike every other gateway I've seen. It's in Perl, and it's still a bit alpha-ish, but it is also exactly what you are looking for and in active development, so you'll have to decide whether that meets your needs. If you're interested in more information or need help, contact me at jbowers@barracuda.com . Compiling may be a bit of a chore, but I've managed it on a couple of different Linux systems now.
    - 18y ago

deleted 18y ago

[deleted]

thwarted 18y ago

Once I get it working, I love it, but there's two problems I've always had with getting XMPP working from a programming/developing standpoint, both of which kept it from going mainstream sooner: 1) there were very few docs that explain the terms (roster, what a conference server is and why that is different from your regular connect server) in the context of other messaging protocols (AIM, for example). Yeah, I know now that "roster" is the equivalent of the buddy list, except it's not because there are operations that can happen on the roster and it's not complete clear which component maintains the roster and a lot of roster operations can happen asynchronously (due do its distributed nature) even when you're disconnected. None of this was obvious. 2) The docs that did exist, even for abstraction libraries, talked about creating XML stanzas and the XML stream and all the different XML namespaces (none of which were explained well enough to know when you would use 'em) and XML this and XML that. I don't want to write XML, I want to connect to a server and send and receive messages. That it is XML stream based is beside the point--and this was always touted as the reason that XMPP was so awesome, but we all know that it got caught up in the XML hype of the period in which it was conceived. Eventually, libraries started being written that provided the correct level of abstraction for developers rather than protocol designers. Last one I used was Net::Jabber::Bot (cpan), which was okay, but there's still a lot of data extraction from partially cooked XML structures.

bjclark 18y ago

This guy obviously hasn't actually used xmpp in real life. eJabberd does really weird things to us when we throw 300-400k messages at it a day. And this: "XMPP servers, which are essentially make or break an XMPP application, are rapidly maturing beyond instant messaging." Have he ever tried to actually debug ejabberd? Cause it's very painful and time consuming. Now, I'm not bashing xmpp, it's pretty cool, but it's not exactly "the next big thing", IMO. We're actually abandoning it for AMPQ.

icepick 18y ago
"eJabberd does really weird things to us". Describe the weird things, please. I'm about to deploy ejabberd for a production site, and I'm interested in your experience.
- bjclark 18y ago
  Huge processor spikes which we think are caused by too many connections to a single room or user. We're not 100% sure because we can't replicate it in a dev environment and we don't really want to turn on debugging in a production environment, not to mention that debugging mode isn't the most helpful thing ever. If you start it up in "live" mode (ejabberdclt live), we see "Replacing connection..." sometimes, which then throws a "Broken Pipe" error in our rails app. But again, we can't isolate what's happening there.
- known 18y ago
  XMPP is XML based and need heavy processing power (for e.g. not suitable for mobile platform) whereas AMPQ is a binary protocol. http://www.deepdarc.com/2008/02/14/mobile-xmpp/ http://www.deepdarc.com/2008/02/14/mobile-xmpp/
- stephenjudkins 18y ago
  Keep in mind that the problems we're having aren't with XMPP, per se, just with ejabberd. Ejabberd worked flawlessly for several months until it started exhibiting some very strange behavior and performance characteristics. We upgraded to a newer version and we suddenly ran into another, different set of strange behaviors. That said, word on the street is that ejabberd is the best implementation of an XMPP server. AMQP supposedly offers better reliability (with RabbitMQ) as well as a whole lot of pretty cool features that Jabber really doesn't.