[scrollaway]

Sad as it may be, it's pretty clear at this point that XMPP won't be the communication protocol of the future. Everyone who ever seriously worked on it seem to have come out of the experience a broken man. Setting it up requires pretty deep knowledge and the promises of compatibility with most XMPP servers break down pretty fast unless you know which extensions to support.

All these problems are fixable but I don't see the tide ever actually changing direction and "hey suddenly XMPP is cool again, we should all use it".

One thing is for certain... humanity needs standard, open and widely-used protocols for communication. And there's a lot of ground to cover: Text, audio, video; single and multiuser; topical (IRC-like); social (invite-based/people I know); Synchronous (IM) and asynchronous (email/offline messaging)...

XMPP tried to do a lot of that. Maybe it tried to do too much. Maybe you just can't do all that in one protocol. I don't know, I just hope we'll get there soon - if nothing else, I'm tired of maintaining those "best way to reach me" charts JoshM33k is talking about.

[catern]

>Setting it up requires pretty deep knowledge

Not even remotely true! Prosody on Debian works out of the box, including federation. You just have to configure the domain name.

It's not hard to set up an XMPP server. It's hard to set up Ejabberd. Ejabberd is not the only XMPP server. Prosody is very easy to set up.

Honestly, people, think before you speak...

[scrollaway]

> Honestly, people, think before you speak...

I didn't just make this up on the spot, I've been dealing with these issues for years. So yes, I've thought about them a lot.

I used to run a prosody server on my home box. It is great software and a fantastic daemon compared to ejabberd (edit: Configuration-wise that is) but fat lot of good that does if you don't know what XEPs to set up when dealing with other servers. I shut it down because it was pretty much useless and I wasn't able to talk to my gtalk buddies from it anymore.

[catern]

> fat lot of good that does if you don't know what XEPs to set up when dealing with other servers.

I have no idea what XEPs to set up when dealing with other servers. I did not have to set up any such thing. Like I said, federation (server to server communication) works out of the box, at least on Debian.

[sanderjd]

Your comment is informative, but the last sentence is unnecessary and inflammatory.

[catern]

You're right. I would delete it, but it's past the edit deadline.

[PhasmaFelis]

> Honestly, people, think before you speak...

Was that really necessary?

[dorfsmay]

I've been using OpenFire, no problem there either.

I had never heard of Prosody, any major difference cons/pros between the two?

[rdtsc]

Yap. Agreed. XMPP looked good on paper, if you read just the mission statement. Thinking back, I tried to dive into it once and nope-d out of it quickly. I guess I just blocked that experience out of my mind for some reason.

[fletchowns]

Who might be the right entity to take on creating a replacement for XMPP?

[scrollaway]

¯\_(ツ)_/¯

One of the best things that could happen today I think is Google open sourcing the Hangouts protocol. It's a reasonable alternative to XMPP and has a massive userbase. The clients are pretty horrible but that might be completely unrelated to how good the protocol is (Note: I have no idea how good it is. Because it's closed source.).

I was hopeful for a while but I don't really see it happening anymore :( Oh well...

Edit: Oh and the worst part: Communication is just one side of that coin. The other side is identity and it's one hell of a side. OpenID was a disaster. Mozilla got it mostly right with Persona but completely botched the marketing and has all but given up on it now. There is no decent foss protocol for identity/authentication today other than Persona, and nobody is working on one. There was a time indeed where I could've pictured Google working on solving this just for the hell of it. Just because it would improve the world. That Google is gone, and there's nobody with the appropriate reach that seems willing to do it now.

[StavrosK]

I will forever mourn and be angered by Mozilla giving up on Persona so easily.

[fletchowns]

Why is Persona dead? Visiting the site doesn't seem to give any indication it's dead...

[StavrosK]

What notatoad said, plus I don't think they're maintaining things very well any more. Last time I tried to use the ecosystem, various non-core things were breaking. Huge pity, it's a very well-designed protocol.

[notatoad]

It's been "given to the community" or something like that. They didn't kill it, but they aren't paying any staff to work on it anymore.

[lukeh]

Persona was great and it's a bit sad to see it dead after investing a lot of time in it but - one big architectural problem was there was no way to support delegation (the problem OAuth was originally designed to solve).

[e12e]

Has anyone got experience with both XMPP and SIP/H.323? From what I've been able to figure out, H.323 looks like it's one of the better candidates of protocols that exist today and is "reasonably" simple... while SIP... well, SIP smells a lot like it came from big TelCos. And not in a good way.

See eg: https://www.packetizer.com/ipmc/h323_vs_sip/

[jallmann]

> Has anyone got experience with both XMPP and SIP/H.323?

I've worked with all three. The H.323 vs SIP battle was fought a long time ago... for better or worse, SIP won. Any H.323 systems still in the wild can probably be considered "legacy."

That being said, while H.323 has more "batteries included," its call flow is accordingly more complex. SIP is not too bad, there is some subtlety to it, but the main issue is that you have to piece together dozens of RFCs for an interoperable system, not to speak of implementation-specific quirks.

XMPP is the more appropriate protocol in this context -- IM and group chat -- because it has had presence and ad-hoc messaging baked in from the start, including reasonably supported MUC. Ultimately, XMPP's issues are similar to SIP's -- the patchwork of XEPs is too unwieldy to work with. For an example, compare the multimedia bits (eg, Jingle) and the corresponding SIP session setup flow. The stigma of being a XML-based protocol designed in the 90's doesn't help, either.

The biggest reason SIP is sticking around, however, is that it has major buy-in from the telcos with IMS/4G. However, SIP is also a more appropriate protocol for traditional telephony. In that respect, comparing SIP and XMPP is a bit like comparing apples to oranges. With the appropriate extensions, one could behave like the other, but it wouldn't be their strength.

[fletchowns]

What are some of the reasons it's hard to design a good messaging protocol?

[jallmann]

If you know your requirements up front, then it's not hard. In fact, it's a good exercise to do so -- probably one reason why messaging systems are a dime a dozen nowadays. What's hard is making a messaging system that is everything for everybody. If SIP or XMPP has taught us anything, it's that "extensibility" is a killer. Requirements evolve, and often it is perceived as easier or "cleaner" to start from scratch, rather than work around the idiosyncrasies of existing systems.

On the other hand, if you are trying to design a protocol to solve a domain specific problem (eg, in cryptography, multimedia, distributed systems, etc) then it becomes more of a research endeavor with all the associated pitfalls. In that case, there will always be the "shoulders of giants" to build off of. Unfortunately though, for every pioneering TextSecure, there are a dozen CryptoCats repeating the same mistakes of years past...

[e12e]

Sigh, sorry to hear that. I was hoping h.323 might work well for a personal call system with the option of ditching regular cell service. And just try and brute force most communication through h.323 :-/

It seems obvious multimedia calls is part of our future, and I refuse to let that be dictated by corporate lock-in -- be that Skype/Lync, Hangouts or whatever Facebook will launch when they enable videochat. And any videochat/conference needs text messaging/conversations too, so it seems like it would be nice to run everything through one server/service.

Which I had hoped made sense would be a h.323 server (along with open source clients+maybe a websocket/web-client bridge).

Guess it'll have to be SIP for phone (so I can ditch my regular cell service), maybe SIP for videochat (but I'm sceptical about the videoconferencing bit)... and XMPP for messaging.

As neither Facebook, Google nor Microsoft support either XMPP in general (making it feasible to set up a bridge server) anymore, nor federation (which would actually be useful), I suppose I'll just have to give up on the idea that there'll appear a chat network where I'll be able to reach most of my contacts with a Free/Open client that isn't forced to play catchup to corporate whims.

For a while, Facebook via XMPP worked (but not group chat), now it's back to sms. Which is annoying because sms is gated by the telcos, although it should be easy enough to make a xmpp<>sms gateway (eg: [s]) with a spare android phone. For personal use that wouldn't have to incur any sms fees (but would mean keeping a non-free cellular plan).

For others frustrated by the same, there's at least a "traditional" project to reverse-engineer working with FBs current chat: https://github.com/jgeboski/bitlbee-facebook

[s] http://projectmaxs.org/homepage/

[ed: Forgot to commend duckduckgo and fastmail on hosting proper XMPP with federation and registration (at least ddg[d]) enabled. That's one reason why XMPP is nice -- you can actually point non-technical users at a suitable client, and add a couple of screenshots how how to set it up with ddg -- and they can then federate/talk away (that is assuming you don't/can't/won't support registration on your own server -- in my case the main reason not to recommend people wanting to talk to me to register on my server, is that I wouldn't know what kind of "SLA" my own server would have -- so if they used XMPP for other things than talking to me, having an account with someone a little more dedicated to keeping a server open to the general public might be better. But the main point is that that just works with XMPP today. And it should've just worked with both Facebook chat and Google talk/hangouts/newnamehere. And it probably also should've worked with Microsoft accounts/skype/hotmail.

[d] https://duck.co/blog/post/2/using-pidgin-with-xmpp-jabber

]

[jallmann]

> I was hoping h.323 might work well for a personal call system with the option of ditching regular cell service. And just try and brute force most communication through h.323

I guess you could try to run H.323 through a $protocol bridge, but I don't know why you would want to. Retrofitting modern features onto H.323 does not seem like fun. Because if SIP suffers from being too general, H.323 suffers from being way too specific in its architecture and technology requirements -- read through some of the associated specs, eg H.245, and it's not hard to see why SIP won. For the longest time, there was not even the notion of URI addressing...

> SIP for phone ... maybe SIP for videochat (but I'm sceptical

In SIP (and most well-designed protocols), there is no fundamental difference between an audio and a video call. It's just capability negotiation and RTP. Actual interoperability is the problem... and that is one of the reasons vendors like to create closed networks, so they can guarantee the experience end-to-end.

Regarding gating and lock-in: Part of it may be a desire for a proprietary walled garden [1], but a big reason is logistical as well -- one of the reasons Google disabled XMPP federation was because of abuse. This is the same reason you can't dial directly into the PSTN without going through a trusted trunk, and why unlicensed use of cellular frequencies (or any RF, really) is illegal.

[1] Actually, the reason the PSTN is federated is probably more an accident of history than anything else. If not for the AT&T monopoly (and subsequent breakup), people would have been complaining about siloed telephone services 50 years ago! See Tim Wu's The Master Switch for a nice treatment of this.

[paulej]

I was the editor of the H.323 spec years ago. Funny you would say that SIP looks like it comes from the telcos, when the whole aim with SIP was to create just the opposite. H.323 has often been accused of being created by telcos, too. Truth is, folks from the traditional enterprise voice equipment makers shaped both.

SIP was adopted by 3GPP in 1999 to be used in the mobile networks. Of course, that trickled throughout the telcos, so it now is widely used in the telco space. H.323 was widely used for PSTN backhauling to reduce tolls. However, SIP is more prevalent there, I'd guess.

Enterprise networks still use both H.323 and SIP, with more desk phones using SIP and videoconferencing equipment split, but moving to SIP.

That said, any move to SIP these days is only because there is nothing better. WebRTC is the next big thing. It borrows SDP from SIP, but no signaling protocol is defined.

Personally, I'd like to realize the vision behind what was intended to be H.325, which was to be a JSON-based signalling protocol that is fully distributed. Each application could implement whatever protocol it wanted, and they would all be associated through H.325, giving the user the feeling that these different applications work closely together. That would be possible, even when applications run on different devices.

Alas, there seems to be no financial motivator for those that control the market to explore that concept, so we're stuck with H.323, SIP, and WebRTC (and various proprietary glue pieces). The trend these days seems to be toward proprietary solutions, providing limited interop with others through SIP. Limited, as in nothing but basic voice and video.

[e12e]

I recently discovered DTLS and QUIC, of which DTLS appear to be most interesting as a "general use" thing. We do of course not actually have a shortage of protocols, but it'd be nice to have something that was a little more suited for the "new" Internet. Full authentication/encryption, something lighter than TCP for multimedia -- and something that actually has a hope of crossing cheap DSL routers.

QUIC looks interesting, but a) is very concentrated on being a transport for http/2, b) is in flux, and c) Google apparently haven't donated any code that makes sense for production (excepting client-side in Chromium).

DTLS is closely connected with WebRTC, has several implementations (though, apparently no support in Erlang/Elixir yet?) and given the current push behind WebRTC appears to be here to stay.

Honestly, I don't know how interesting "hardware phones" are anymore. As long as one can get something to work over wlan with android, things "should" be real-world deployable. And I don't have 100s of SIP devices, so I don't need to care ;-).

It may turn out that wlan+android+WebRTC+DTLS never achieves the kind of latency needed for good live video/audio... I haven't experimented that much, but hopefully it's "good enough".

At any rate, appears that SIP really is the only interop that currently works. At first glance it does seem a little complex for the use-case of text messages, inconvenient in terms of addressing -- but maybe a core focused on WebRTC/IPv6 with gateways for SIP the way to go.

Either way, I guess as long as no big players want interop, it doesn't really matter. One'll just have to make a solution that works for inter-org/inter-friends communication, with the option to federate with those interesting in joining/building a new network. Doesn't look like it'll be easy to take a bite out of FB Messenger/Google Hangouts/WhatsApp etc.

https://webrtcglossary.com/dtls-srtp/

[lstamour]

Identity is a separate problem. So far, https://www.accountchooser.com and OpenID is winning -- if by winning you mean maintaining a list of very popular email providers and using their APIs. ;-)

[ocdtrekkie]

Yeah, I can't see Google ever either open sourcing Hangouts, or making it possible to federate it. Google's opinion seems to be that everything that is a service or protocol should be a Google API.

[vbezhenar]

https://matrix.org is a promising candidate.

[scrollaway]

I remember reading about matrix when they first announced. Was pretty excited about it, haven't heard anything since. I It's just tech though; even if it's mind-blowingly great, won't do much good if no large-scale userbase picks it up somehow.

[ara4n]

We're still alive and going strong - currently supporting glossy client development like Vector.im and building out bridges to as many other networks as possible (IRC, Slack, HipChat etc) using http://github.com/matrix-org/matrix-appservice-bridge and similar. In terms of being picked up by a large user base... yes, we need it if we are to be really relevant. And that means relying on folks like those commenting on this thread to try using it, contributing to it, and help us make it better.

[scrollaway]

Well I'll do my part on mindshare, I do like what I see :)

Maybe you guys should do another Show HN.

[ara4n]

Whilst we're not trying to replace XMPP, Matrix.org does provide an entirely different architecture (decentralised and evetually-consistent history, high baseline feature set, HTTP-based, etc) that can be used for group chat/VoIP/etc.

[sitkack]

I don't know who will do it, but it will be in-band, meaning inside http and using html5.