4 ms·

Sorry if this is slightly off-topic, but I was wondering if anyone could explain the technical reasons why, with minimal modification, we couldn't just replace

Sorry if this is slightly off-topic, but I was wondering if anyone could explain the technical reasons why, with minimal modification, we couldn't just replace all electronic messaging systems from SMS to email with xmpp, and forevermore live in a magical fantasy world where email headers, text fees and security concerns don't exist? I mean, it has these things going for it- 1. SSL/TLS embedded in the standard. 2. Easy to set up OTR encryption, (as well as any other standard I imagine). 3. Messages are "pushed" to clients, rather than "pulled". 4. The standard is simple, and servers like Prosody are super-easy to implement (unlike Exim). 5. There are plenty of clients already available. Admittedly it's not something I've researched much, but I doubt it'd take all that much to get Adium or whatever to work like a simple email client, (but with xmpp). I'm aware of all of the social reasons why such a thing may not work, but I'd be interested to know if it were just a question of getting people to adopt it, were it to exist.

TylerE 13y ago
Because push doesn't scale.
- MattJ100 13y ago
  Care to elaborate?
  - TylerE 13y ago
    Server has to keep tabs on all clients, rather than being polled.
- scotchmi_st 13y ago
  Really? So there are no large-scale implementations of push-notification systems? Is there some detail I'm missing here?
- eikenberry 13y ago
  Push can scale. Ask Urban Airship. It is hard though and while polling is generally easier it has its own set of scaling problems.
- nknighthb 13y ago
  With a statement like that, you're going against decades of experience which says polling doesn't scale. Constant connection setup and teardown is incredibly expensive. RAM is cheap.
- msh 13y ago
  The apple iOS push service would like to disagree.
jmillikin 13y ago
4: XMPP is many things, but it's definitely not simple or easy to implement. Start with the core spec, RFC 3920. Right away you'll run smack into the problem of XML namespaces, which is a feature that every XML library pretends to support, but with a whole bunch of caveats. Before you can do so much as initiate a session, you will need to search the universe of XML libraries for one that implements a full parser and has good namespace support. (When I wrote an XMPP library, I ended up using libxml2 because the only platform I care about is Linux.) Next you'll have to implement encryption (TLS) and authentication (SASL). As with all security-related code, this part of your application is terribly easy to fuck up in a non-obvious-but-user-endangering way. Does your TLS library check that the certificate is valid? Many don't by default. Does your SASL library implement the spec correctly? SASL is complicated and difficult to test, so it's easy for even experienced developers to break authentication for some subset of users. (I used gnutls and gsasl to do most of the heavy lifting, but still ran into many problems. For example, my library doesn't work with some versions of ejabberd because ejabberd's implementation of SCRAM-SHA-1 was broken: https://support.process-one.net/browse/EJAB-1632 https://support.process-one.net/browse/EJAB-1632). OK, so you've found a full-featured XML library, you've figured out TLS and SASL, and you can send "hello world!" to another account. Think you're done? Hahaha, no my friend, you're just getting started. To do anything interesting with XMPP, you need to implement XMPP extensions (XEPs). There are currently three hundred and twenty seven XEPs, indexed at http://xmpp.org/xmpp-protocols/xmpp-extensions/ http://xmpp.org/xmpp-protocols/xmpp-extensions/ , and many of them are at least as large as the core spec itself. XEPs cover such important functionality as multi-user messaging, file transfer, voice/video chat, full encryption, avatars, and away messages. (I decided to skip all that, not do any XEPs at all, and limit my library to simple one-on-one chats because that's all I needed it for. If you're writing something for use by customers, you will not have that luxury.) And of course, it's all implemented in XML. Hope you've got a sturdy keyboard.
- scotchmi_st 13y ago
  Yeah I would certainly say that building a messaging system of any type with the features of XMPP /from scratch/ would be hard. Then again, just compare the config files of sendmail and exim to prosody or ejabberd. Given that tools for working with xmpp already exist, it does seem a shame to me that it hasn't seen wider adoption. Wasn't Google Wave based on it?
cromwellian 13y ago
SMTP is a delay-tolerant store-and-forward system, XMPP isn't. You can't replace all electronic messaging with a system that can't support DTN attributes.
glomph 13y ago
Because not everyone has a smartphone?

TylerE 13y ago

Because push doesn't scale.

MattJ100 13y ago
Care to elaborate?
- TylerE 13y ago
  Server has to keep tabs on all clients, rather than being polled.
scotchmi_st 13y ago
Really? So there are no large-scale implementations of push-notification systems? Is there some detail I'm missing here?
eikenberry 13y ago
Push can scale. Ask Urban Airship. It is hard though and while polling is generally easier it has its own set of scaling problems.
nknighthb 13y ago
With a statement like that, you're going against decades of experience which says polling doesn't scale. Constant connection setup and teardown is incredibly expensive. RAM is cheap.
msh 13y ago
The apple iOS push service would like to disagree.

jmillikin 13y ago

4: XMPP is many things, but it's definitely not simple or easy to implement. Start with the core spec, RFC 3920. Right away you'll run smack into the problem of XML namespaces, which is a feature that every XML library pretends to support, but with a whole bunch of caveats. Before you can do so much as initiate a session, you will need to search the universe of XML libraries for one that implements a full parser and has good namespace support. (When I wrote an XMPP library, I ended up using libxml2 because the only platform I care about is Linux.) Next you'll have to implement encryption (TLS) and authentication (SASL). As with all security-related code, this part of your application is terribly easy to fuck up in a non-obvious-but-user-endangering way. Does your TLS library check that the certificate is valid? Many don't by default. Does your SASL library implement the spec correctly? SASL is complicated and difficult to test, so it's easy for even experienced developers to break authentication for some subset of users. (I used gnutls and gsasl to do most of the heavy lifting, but still ran into many problems. For example, my library doesn't work with some versions of ejabberd because ejabberd's implementation of SCRAM-SHA-1 was broken: https://support.process-one.net/browse/EJAB-1632 https://support.process-one.net/browse/EJAB-1632). OK, so you've found a full-featured XML library, you've figured out TLS and SASL, and you can send "hello world!" to another account. Think you're done? Hahaha, no my friend, you're just getting started. To do anything interesting with XMPP, you need to implement XMPP extensions (XEPs). There are currently three hundred and twenty seven XEPs, indexed at http://xmpp.org/xmpp-protocols/xmpp-extensions/ http://xmpp.org/xmpp-protocols/xmpp-extensions/ , and many of them are at least as large as the core spec itself. XEPs cover such important functionality as multi-user messaging, file transfer, voice/video chat, full encryption, avatars, and away messages. (I decided to skip all that, not do any XEPs at all, and limit my library to simple one-on-one chats because that's all I needed it for. If you're writing something for use by customers, you will not have that luxury.) And of course, it's all implemented in XML. Hope you've got a sturdy keyboard.

scotchmi_st 13y ago
Yeah I would certainly say that building a messaging system of any type with the features of XMPP /from scratch/ would be hard. Then again, just compare the config files of sendmail and exim to prosody or ejabberd. Given that tools for working with xmpp already exist, it does seem a shame to me that it hasn't seen wider adoption. Wasn't Google Wave based on it?

cromwellian 13y ago

SMTP is a delay-tolerant store-and-forward system, XMPP isn't. You can't replace all electronic messaging with a system that can't support DTN attributes.

glomph 13y ago

Because not everyone has a smartphone?