2 ms·

>> There were several people saying Jabber would kill IRC years ago Who? I doubt anybody knowledgeable would claim that Jabber would kill IRC, since the two p

>> There were several people saying Jabber would kill IRC years ago Who? I doubt anybody knowledgeable would claim that Jabber would kill IRC, since the two protocols serve largely different purposes. Jabber has killed off most of the smaller closed IM networks, and even the large ones are smaller than they once were. As for the claimed difficulty of implementing XMPP, I'd like to see some more references on that. I'm writing an XMPP library now, and it doesn't seem particularly difficult. With only an hour or two of work, it can connect securely to 3rd-party servers and act as a useful bot. With a bit more work, I'm sure it could be a production-quality library. Furthermore, the proliferation of implementations for various languages and platforms suggests that the barrier to entry for an XMPP library is rather low.

axod 17y ago
From a previous thread on XMPP: http://news.ycombinator.com/item?id=426581 http://news.ycombinator.com/item?id=426581 Even the specs for XMPP+extensions seem to be written in XML, running to thousands of pages due to the overly-general-underly-practical nature.
- jmillikin 17y ago
  Yes, it's difficult to establish a secure connection. This is due to the nature of security in general, and is not inherent to XMPP. If you want to just write plain-text messages without authentication, you could do so with netcat. If you want to use digest-auth and SSL, obviously the client and server will be more complicated. Many servers will outright refuse to authenticate a connection unless it's using TLS and digest auth, which is an excellent idea. I don't think expecting any modern protocol to support typing commands in by hand over netcat/telnet is reasonable.
  - axod 17y ago
    $ openssl s_client -connect irc.mibbit.com:6697 Works for me... In comparison, it's not possible to use a general tool to do anything like this with XMPP, because it's all wrapped in endless XML complexity.
    - jmillikin 17y ago
      You've yet to state how using XML as a serialization layer introduces any additional complexity into XMPP. Your example doesn't support TLS upgrading, forcing TLS and plaintext connections to be handled on separate ports. You also ignore authentication and authorization, which are much more important than merely opening an encrypted socket to some arbitrary server. IRC is a nice protocol for things that don't matter, but it's utterly unsuitable for applications that require security or features beyond "send text and hope some client receives it, eventually".
      - axod 17y ago
        It's about 3 times the bandwidth for a start. I agree @TLS, authorization etc, but often those just aren't a priority. email is often used without any security but it's far from something that "doesn't matter". IM protocols have barely any security, yet we all use them.
        jmillikin 17y ago
        3 times epsilon is still epsilon. The bandwidth taken by plain text, even assuming worst case overhead of many small one-character messages, is inconsequential compared to images or videos. E-mail has optional security for things that do matter, namely GPG/PGP for client <-> client and the STARTTLS extension to SMTP for server <-> server. Wave, as a replacement for E-mail, provides pervasive security. "IM protocols have barely any security" -- given that this discussion is regarding an IM protocol with a built-in high-quality security infrastructure, I don't see how this statement is at all valid.
        axod 17y ago
        >> "IM protocols have barely any security" -- given that this discussion is regarding an IM protocol with a built-in high-quality security infrastructure, I don't see how this statement is at all valid. I was talking about the main IM protocols in use today - yahoo/msn/aim. You'd be surprised @ plain text. It quickly adds up. I do around 3.5TB of plain text IRC/http a month, and if I could reduce that, I would. If we were all using jabber instead of IRC my bandwidth would be more like 10TB. Quite a difference. >> "E-mail has optional security for things that do matter, namely GPG/PGP for client <-> client and the STARTTLS extension to SMTP for server <-> server. Wave, as a replacement for E-mail, provides pervasive security." That comes back to my original comment - I'm not sure it solves any real world problem users have. Users don't care about security like that.
wooster 17y ago
I wrote a Jabber client for OS X public beta back in 2000. It was a horrendous pain in the ass. I was also on the IMPP working group list for a few years. The big standout problem with XMPP is "XML streaming", which is fairly difficult to handle tersely, correctly, securely, and reliably. Mostly this is because parsing streaming XML (using, say, SAX) usually involves writing a lot of one-off code. Most of that code is just going to be making sure your messages correspond to the spec, don't start getting too deep, are complete, etc. Then there's the out of band data stuff, which at the time, was basically undefined. Now, it's defined, in a whole lot of specs. Then there's RTF, which is used by several Windows clients as a message format. That's what I remember, at least, and skimming the current RFC's suggests things haven't changed much.

axod 17y ago

From a previous thread on XMPP: http://news.ycombinator.com/item?id=426581 http://news.ycombinator.com/item?id=426581 Even the specs for XMPP+extensions seem to be written in XML, running to thousands of pages due to the overly-general-underly-practical nature.

jmillikin 17y ago
Yes, it's difficult to establish a secure connection. This is due to the nature of security in general, and is not inherent to XMPP. If you want to just write plain-text messages without authentication, you could do so with netcat. If you want to use digest-auth and SSL, obviously the client and server will be more complicated. Many servers will outright refuse to authenticate a connection unless it's using TLS and digest auth, which is an excellent idea. I don't think expecting any modern protocol to support typing commands in by hand over netcat/telnet is reasonable.
- axod 17y ago
  $ openssl s_client -connect irc.mibbit.com:6697 Works for me... In comparison, it's not possible to use a general tool to do anything like this with XMPP, because it's all wrapped in endless XML complexity.
  - jmillikin 17y ago
    You've yet to state how using XML as a serialization layer introduces any additional complexity into XMPP. Your example doesn't support TLS upgrading, forcing TLS and plaintext connections to be handled on separate ports. You also ignore authentication and authorization, which are much more important than merely opening an encrypted socket to some arbitrary server. IRC is a nice protocol for things that don't matter, but it's utterly unsuitable for applications that require security or features beyond "send text and hope some client receives it, eventually".
    - axod 17y ago
      It's about 3 times the bandwidth for a start. I agree @TLS, authorization etc, but often those just aren't a priority. email is often used without any security but it's far from something that "doesn't matter". IM protocols have barely any security, yet we all use them.
      - jmillikin 17y ago
        3 times epsilon is still epsilon. The bandwidth taken by plain text, even assuming worst case overhead of many small one-character messages, is inconsequential compared to images or videos. E-mail has optional security for things that do matter, namely GPG/PGP for client <-> client and the STARTTLS extension to SMTP for server <-> server. Wave, as a replacement for E-mail, provides pervasive security. "IM protocols have barely any security" -- given that this discussion is regarding an IM protocol with a built-in high-quality security infrastructure, I don't see how this statement is at all valid.
        axod 17y ago
        >> "IM protocols have barely any security" -- given that this discussion is regarding an IM protocol with a built-in high-quality security infrastructure, I don't see how this statement is at all valid. I was talking about the main IM protocols in use today - yahoo/msn/aim. You'd be surprised @ plain text. It quickly adds up. I do around 3.5TB of plain text IRC/http a month, and if I could reduce that, I would. If we were all using jabber instead of IRC my bandwidth would be more like 10TB. Quite a difference. >> "E-mail has optional security for things that do matter, namely GPG/PGP for client <-> client and the STARTTLS extension to SMTP for server <-> server. Wave, as a replacement for E-mail, provides pervasive security." That comes back to my original comment - I'm not sure it solves any real world problem users have. Users don't care about security like that.

wooster 17y ago

I wrote a Jabber client for OS X public beta back in 2000. It was a horrendous pain in the ass. I was also on the IMPP working group list for a few years. The big standout problem with XMPP is "XML streaming", which is fairly difficult to handle tersely, correctly, securely, and reliably. Mostly this is because parsing streaming XML (using, say, SAX) usually involves writing a lot of one-off code. Most of that code is just going to be making sure your messages correspond to the spec, don't start getting too deep, are complete, etc. Then there's the out of band data stuff, which at the time, was basically undefined. Now, it's defined, in a whole lot of specs. Then there's RTF, which is used by several Windows clients as a message format. That's what I remember, at least, and skimming the current RFC's suggests things haven't changed much.