5 ms·

Have you seen XMPP? Chat is so much more than just text now; it's "voicemail", and "photos", and "videos", and "stickers", and "Western Union" and "voice calls"

by cbhl 11y ago

Have you seen XMPP? Chat is so much more than just text now; it's "voicemail", and "photos", and "videos", and "stickers", and "Western Union" and "voice calls" and "video calls" and so much more. Plus, XMPP, is, like, XML. Open protocols and federation are cool and all, but XMPP is not the protocol that will let someone be competitive in this space. (Disclaimer: I work at Google. This is my opinion. I do not work on Hangouts.)

jkarneges 11y ago
Standards tend to run behind the state-of-the-art, but that's not a reason to avoid them. For example, the iPhone continues to support SMS for interaction with non-iPhone users, even though the iMessage protocol is richer. If Facebook valued compatibility with as many different products as possible, then they would keep XMPP support. The issue is not about features or XML. Most likely, it's about them wanting full control over the end-user experience: "We recommend people access Facebook Messages on the desktop via Facebook.com or Messenger.com."
- enos_feedler 11y ago
  An interesting question is "why do standards tend to run behind state-of-the-art"? There are so many examples of this in the past (coming from a graphics background, OpenCL vs. CUDA). Is this something we can fix? Perhaps it is about providing the right hooks into the specification to not compromise the end user experience. I think Docker is an interesting project to follow in this regard. They have shown the ability to get both startups and large players (amazon, google, microsoft) onboard by keeping the platform open. Yet they are clearly focused on providing the best experience for developer/ops interaction with cloud services. It will be interesting to see the rollout of their extension mechanisms and whether they can be a primary interface to cloud services or will become a second-teir compatibility layer. However, even in this case perhaps chat protocols could learn something here.
  - spacehunt 11y ago
    > why do standards tend to run behind state-of-the-art Because otherwise you end up with design-by-committee.
  - rakoo 11y ago
    I think the real problem with XMPP (and the visible lag between state of the art and specifications) is that there's no single big vendor behind it. It's both a pro (in that the specs should accommodate what the community wants, not what the vendor wants) and a con (because specs are written when vendors feel like it). An interesting example is Google with SPDY. They wanted something new, built it, tested it, and then wrote the specifications (along with other actors of course). I think it is fair to say that without the SPDY experiment we wouldn't have seen HTTP/2 coming so fast. Google and the other actors had enough incentive (and actual time and money to spend) to make it go further. In the case of XMPP there's no such actor, unfortunately.
    - enos_feedler 11y ago
      Yeah, good point. USB-C wouldn't have ratified so quickly if Apple didn't hand it over [1]. Apple could also be credited with putting pressure on OpenGL to release Vulcan when they released Metal API a year prior. Before this, OpenCL/GL hand't changed drastically in years. It seems big companies are involved whenever positive momentum happens. [1] http://9to5mac.com/2015/03/14/apple-invent-usb-type-c/ http://9to5mac.com/2015/03/14/apple-invent-usb-type-c/
  - dragonwriter 11y ago
    > An interesting question is "why do standards tend to run behind state-of-the-art"? There are so many examples of this in the past (coming from a graphics background, OpenCL vs. CUDA). Is this something we can fix? Its not broken. Standards are, ideally, distillations and applications of proven experience in a generally applicable way. You don't want standards trying to ride the bleeding edge, they want them to apply what is proven. (OTOH, its good to have those working on the bleeding edge also opening for discussion how those experiments might be standardized while the experiments are still ongoing, and one vehicle for those discussions is draft standards or draft updates to existing standards.)
stephenr 11y ago
You do know that several major, closed IM networks are in fact built on XMPP, with custom extensions and no federation (hence making them "closed")?
Sir_Substance 11y ago
Why do I feel that "be competitive" is a euphemism for "nailgun users feet to the ground by locking them into everything possible"? I'll be honest with you my friend. I would prefer to physically mail people coins then use facebook/google/apple pay. As much as I distrust banks, they at least have a record of letting me move to a competitor if I ask.
- raverbashing 11y ago
  > Why do I feel that "be competitive" is a euphemism for "nailgun users feet to the ground by locking them into everything possible"? Then create an open protocol that supports what the users want
  - seanp2k2 11y ago
    Users want Snapchat using the Snapchat client without having to maintain a second account or re-find all their friends. Same with Facebook, Hangouts, Skype, etc. the ship for federation sailed when all the big players decided to kill XMPP and not try a new open standard.
- stephenr 11y ago
  I'm not sure what relation Apple or Google payment systems have to chat?
anc84 11y ago
Not sure what you mean by "voicemail" and "videos". Photos: No problem with XMPP. Just inline them if you want. Voice calls, video calls: Easily done with Jingle, which is a XMPP standard. Stickers: See above, they are just a special form of smilies which like any client supports. And so much more: http://xmpp.org/xmpp-protocols/xmpp-extensions/ http://xmpp.org/xmpp-protocols/xmpp-extensions/ I wonder if you know what Whatsapp is based on.
- rakoo 11y ago
  While there are XEPs to define these extensions, there is a huge gap between "you can do it" and "it's done here". Could you cite at least 1 client that does all of the above on each platform (Linux, Windows, Mac OS, WP, Android, iOS) ? (This is a genuine question, I'd like to know if it really is possible, especially on mobile)
  - anc84 11y ago
    I share your pain, the state of actual implementations is sad. I don't know any (combination) of clients that do it all. Jitsi is pretty good but ugly and desktop only. Gajim is really good. Conversations is great for text on Android 4+. It is no surprise that Whatsapp and the like are so successful. Textsecure/Signal is being too slow, I am afraid they missed their window of opportunity for fast widespread adoption.
heavenlyhash 11y ago
Having recently started working on a chat client that was intended to speak first-and-foremost XMPP, I have to agree: XMPP is... it's decades out of date and missing a number of absolutely critical, central ideas that are essential to making stuff work. Examples: - unique message IDs? Absent. XEPs kind of provide; but I can't tell you which of the three or for relevant ones are the most relevant (AMP IDs from XEP 0079? Stream Management from XEP 0198? Acking from XEP 0184? Something from Carbons or MAM in 0313 or 0280? You know, if you wanted some light reading...). - multi device? Oh. My. God. It's bananas. The spec behavior is that whenever a client sends a message, the server is supposed to consider that one the most alive, and then route all future messages exclusively to that one. So you send a message on your phone? Yeah, your desktop is just going to silently stop receiving messages. - there's a concept of "message carbons" to deal with this. This involves re-sending all your messages back to the server after you receive them, with special instructions to send them back again to your other clients. The amount of redundantly redundant XML involved is eyewatering. Combine that multidevice behavior (messages can get randomly routed anywhere at any time) with the wild-west nature of message delivery acks, and you can see how ridiculously difficult this makes the basic idea of "all clients should see the same picture". Overall, the XEP process, conceptually, is a great example of open extensibility. The trouble is, so much of this stuff is core to sane message delivery semantics that it really, practically speaking, causes huge problems when it's all considered "extensions". Stuff like message IDs fundamentally shouldn't be an extension because it's just too critical that all minimum-viable clients agree. You just can't build higher level stuff without that. XEPs are great. A community process for extensions should exist. It just needs to exist for extensions, not subsume the total set of realistic minimum viable features. I want an open chat protocol. I thought XMPP might be the one. Then, as the parent comment jibes, I actually looked at it. Tried to write something with it. XMPP is not prepared to be the one, in any sense at all except for legacy support. I have all the respect in the world for all the folks who put effort into trying to make an open chat standard, but... honestly, we need a stronger foundation than this.
- heavenlyhash 11y ago
  Since this seems to be resonating with a lot of folks, I'll also follow with something more constructive: What I'd like to see is a messaging system that gets the basics right, and that's deeply aware that it's AP out of CAP. Messages are inherently commutative (think CRDTs) and can be received in arbitrary order; people on two sides of a partition should have no trouble reconciling coherent logs regardless of if there was a two minute netsplit or someone was backpacking for two weeks. I'm looking for any existing stuff that suits this, and willing to collaborate on making it if it needs to be made!
hobarrera 11y ago
> "photos" File transfers, nothing new here. > "videos" Either file transfer, or live voice+video. Neither are new. I last used XMPP+voice+video about five years ago. > "stickers" Image transfers. Or custom emoticons with a large size. Again, nothing new. > "Western Union" ??? > "voice calls" Again, nothing new about this.
seanp2k2 11y ago
Speaking of Google, GChat supported XMPP at one point too, and we could have had cross-service federation if all the big companies would have played ball: http://www.disruptivetelephony.com/2015/02/google-finally-kills-off-googletalk-and-xmpp-jabber-integration.html http://www.disruptivetelephony.com/2015/02/google-finally-ki... Why not work on pushing an open standard instead of locking users into your proprietary client? I already know the answer (ads and user data collection; see also: G+), it just leaves a bad taste in my mouth #dontBeEvil

by cbhl 11y ago

jkarneges 11y ago

Standards tend to run behind the state-of-the-art, but that's not a reason to avoid them. For example, the iPhone continues to support SMS for interaction with non-iPhone users, even though the iMessage protocol is richer. If Facebook valued compatibility with as many different products as possible, then they would keep XMPP support. The issue is not about features or XML. Most likely, it's about them wanting full control over the end-user experience: "We recommend people access Facebook Messages on the desktop via Facebook.com or Messenger.com."

enos_feedler 11y ago
An interesting question is "why do standards tend to run behind state-of-the-art"? There are so many examples of this in the past (coming from a graphics background, OpenCL vs. CUDA). Is this something we can fix? Perhaps it is about providing the right hooks into the specification to not compromise the end user experience. I think Docker is an interesting project to follow in this regard. They have shown the ability to get both startups and large players (amazon, google, microsoft) onboard by keeping the platform open. Yet they are clearly focused on providing the best experience for developer/ops interaction with cloud services. It will be interesting to see the rollout of their extension mechanisms and whether they can be a primary interface to cloud services or will become a second-teir compatibility layer. However, even in this case perhaps chat protocols could learn something here.
- spacehunt 11y ago
  > why do standards tend to run behind state-of-the-art Because otherwise you end up with design-by-committee.
- rakoo 11y ago
  I think the real problem with XMPP (and the visible lag between state of the art and specifications) is that there's no single big vendor behind it. It's both a pro (in that the specs should accommodate what the community wants, not what the vendor wants) and a con (because specs are written when vendors feel like it). An interesting example is Google with SPDY. They wanted something new, built it, tested it, and then wrote the specifications (along with other actors of course). I think it is fair to say that without the SPDY experiment we wouldn't have seen HTTP/2 coming so fast. Google and the other actors had enough incentive (and actual time and money to spend) to make it go further. In the case of XMPP there's no such actor, unfortunately.
  - enos_feedler 11y ago
    Yeah, good point. USB-C wouldn't have ratified so quickly if Apple didn't hand it over [1]. Apple could also be credited with putting pressure on OpenGL to release Vulcan when they released Metal API a year prior. Before this, OpenCL/GL hand't changed drastically in years. It seems big companies are involved whenever positive momentum happens. [1] http://9to5mac.com/2015/03/14/apple-invent-usb-type-c/ http://9to5mac.com/2015/03/14/apple-invent-usb-type-c/
- dragonwriter 11y ago
  > An interesting question is "why do standards tend to run behind state-of-the-art"? There are so many examples of this in the past (coming from a graphics background, OpenCL vs. CUDA). Is this something we can fix? Its not broken. Standards are, ideally, distillations and applications of proven experience in a generally applicable way. You don't want standards trying to ride the bleeding edge, they want them to apply what is proven. (OTOH, its good to have those working on the bleeding edge also opening for discussion how those experiments might be standardized while the experiments are still ongoing, and one vehicle for those discussions is draft standards or draft updates to existing standards.)

stephenr 11y ago

You do know that several major, closed IM networks are in fact built on XMPP, with custom extensions and no federation (hence making them "closed")?

Sir_Substance 11y ago

Why do I feel that "be competitive" is a euphemism for "nailgun users feet to the ground by locking them into everything possible"? I'll be honest with you my friend. I would prefer to physically mail people coins then use facebook/google/apple pay. As much as I distrust banks, they at least have a record of letting me move to a competitor if I ask.

raverbashing 11y ago
> Why do I feel that "be competitive" is a euphemism for "nailgun users feet to the ground by locking them into everything possible"? Then create an open protocol that supports what the users want
- seanp2k2 11y ago
  Users want Snapchat using the Snapchat client without having to maintain a second account or re-find all their friends. Same with Facebook, Hangouts, Skype, etc. the ship for federation sailed when all the big players decided to kill XMPP and not try a new open standard.
stephenr 11y ago
I'm not sure what relation Apple or Google payment systems have to chat?

anc84 11y ago

Not sure what you mean by "voicemail" and "videos". Photos: No problem with XMPP. Just inline them if you want. Voice calls, video calls: Easily done with Jingle, which is a XMPP standard. Stickers: See above, they are just a special form of smilies which like any client supports. And so much more: http://xmpp.org/xmpp-protocols/xmpp-extensions/ http://xmpp.org/xmpp-protocols/xmpp-extensions/ I wonder if you know what Whatsapp is based on.

rakoo 11y ago
While there are XEPs to define these extensions, there is a huge gap between "you can do it" and "it's done here". Could you cite at least 1 client that does all of the above on each platform (Linux, Windows, Mac OS, WP, Android, iOS) ? (This is a genuine question, I'd like to know if it really is possible, especially on mobile)
- anc84 11y ago
  I share your pain, the state of actual implementations is sad. I don't know any (combination) of clients that do it all. Jitsi is pretty good but ugly and desktop only. Gajim is really good. Conversations is great for text on Android 4+. It is no surprise that Whatsapp and the like are so successful. Textsecure/Signal is being too slow, I am afraid they missed their window of opportunity for fast widespread adoption.

heavenlyhash 11y ago

Having recently started working on a chat client that was intended to speak first-and-foremost XMPP, I have to agree: XMPP is... it's decades out of date and missing a number of absolutely critical, central ideas that are essential to making stuff work. Examples: - unique message IDs? Absent. XEPs kind of provide; but I can't tell you which of the three or for relevant ones are the most relevant (AMP IDs from XEP 0079? Stream Management from XEP 0198? Acking from XEP 0184? Something from Carbons or MAM in 0313 or 0280? You know, if you wanted some light reading...). - multi device? Oh. My. God. It's bananas. The spec behavior is that whenever a client sends a message, the server is supposed to consider that one the most alive, and then route all future messages exclusively to that one. So you send a message on your phone? Yeah, your desktop is just going to silently stop receiving messages. - there's a concept of "message carbons" to deal with this. This involves re-sending all your messages back to the server after you receive them, with special instructions to send them back again to your other clients. The amount of redundantly redundant XML involved is eyewatering. Combine that multidevice behavior (messages can get randomly routed anywhere at any time) with the wild-west nature of message delivery acks, and you can see how ridiculously difficult this makes the basic idea of "all clients should see the same picture". Overall, the XEP process, conceptually, is a great example of open extensibility. The trouble is, so much of this stuff is core to sane message delivery semantics that it really, practically speaking, causes huge problems when it's all considered "extensions". Stuff like message IDs fundamentally shouldn't be an extension because it's just too critical that all minimum-viable clients agree. You just can't build higher level stuff without that. XEPs are great. A community process for extensions should exist. It just needs to exist for extensions, not subsume the total set of realistic minimum viable features. I want an open chat protocol. I thought XMPP might be the one. Then, as the parent comment jibes, I actually looked at it. Tried to write something with it. XMPP is not prepared to be the one, in any sense at all except for legacy support. I have all the respect in the world for all the folks who put effort into trying to make an open chat standard, but... honestly, we need a stronger foundation than this.

heavenlyhash 11y ago
Since this seems to be resonating with a lot of folks, I'll also follow with something more constructive: What I'd like to see is a messaging system that gets the basics right, and that's deeply aware that it's AP out of CAP. Messages are inherently commutative (think CRDTs) and can be received in arbitrary order; people on two sides of a partition should have no trouble reconciling coherent logs regardless of if there was a two minute netsplit or someone was backpacking for two weeks. I'm looking for any existing stuff that suits this, and willing to collaborate on making it if it needs to be made!

hobarrera 11y ago

> "photos" File transfers, nothing new here. > "videos" Either file transfer, or live voice+video. Neither are new. I last used XMPP+voice+video about five years ago. > "stickers" Image transfers. Or custom emoticons with a large size. Again, nothing new. > "Western Union" ??? > "voice calls" Again, nothing new about this.

seanp2k2 11y ago

Speaking of Google, GChat supported XMPP at one point too, and we could have had cross-service federation if all the big companies would have played ball: http://www.disruptivetelephony.com/2015/02/google-finally-kills-off-googletalk-and-xmpp-jabber-integration.html http://www.disruptivetelephony.com/2015/02/google-finally-ki... Why not work on pushing an open standard instead of locking users into your proprietary client? I already know the answer (ads and user data collection; see also: G+), it just leaves a bad taste in my mouth #dontBeEvil