Especially Jabber/XMPP was created to fix that issue by standardizing the protocol. The idea is that IM would be like email - no central server.
Others (GTalk, Facebook, WhatsApp, HipChat to name few) started implementing it but did not enable server to server communication (ok GTalk did, but as soon as they became popular they intentionally broke it with Hangouts).
So now we have bunch of services that use same protocol but still can't communicate with each other, the XMPP seems like it is dying.
A while ago there were plenty of server-side transports to help migrate to XMPP, but it doesn't seem like they are no longer being developed.
I don't understand why no one cares anymore about decentralizing and standardizing IM.
People do care, it just seems as though they care about their pet peeves more.
* This eliminates the whole issue for users (I don't want to have to remember 40 million passwords, and I don't want to rely on Google as my SSO).
* It helps the developer because all he has to do is implement one protocol (rather than make 8 different accounts to register passport.js with).
* It helps the tin-foil hatters like me, because I can revoke access from any source at any time & if my account gets compromised I call my buddy Bill hosting the IDP and invalidate my credentials.
I've been working on this problem on and off for about 10 months, the last 4 of which have been fairly rigorous. I've got a solution for the "buddy" willing to host the IdP. https://github.com/bergie/passport-saml is a low friction add-on to your node app for the developers. The last piece of the puzzle is dev adoption (i.e., getting traction on par with LetsEncrypt) to actually spend 5 minutes for that passport-saml stuff.
The other issue is developing an easy solution (easier than SSO with Google) done by mobile App authentication. User-flow is basically: you click "Login with <name>", the IdP forwards the message to your mobile via APN, and you swipe left or right to auth. That's the last technical barrier (user adoption is 80% of the problem). I need to take ~3 mo off and pony up high-five, low-sixes in fees re: getting a great UX guy (I'm abysmal [[if you're great at UX, contact me]]), lawyers, liability insurance, a security firm to audit, etc (there's already a monetization model for this venture, though the whole thing will be GNU AGPL[3] / free for universities / research institutions, etc.)
[0] Like, in the formal mathematically proven sense, both in concept, and implementation (though which one slips my mind).
[1] http://wso2.com/library/articles/2010/07/saml2-web-browser-b...
[2] Encryption is basically a subset of privacy, which I think we have a constitutional right to, though other people object.
[3] The whole point is to do this first as a human good, but profiteer off expensive licenses a la Exchange modules, et al. I don't really want to shop around Sandy Hill but if any of you successful Angels (who are historically privacy advocates, I'd give Karsten Nohl or DJB (or hell, PG if you're reading this message haha, 30% and 2 seats in a second, but Larry Ellison could offer 3MM for .1% and that meeting would conclude rapidly) are interested, e-mail me me -- we'd be able to go to market a lot quicker with 2 or 3 FTE's. I'm going to complete this anyways, but we're fighting cryptowars again so there might be a rush.
The problem is non-techies do not understand why email is good while messaging is bad. There is no indication as to where these problems would come from, and they have no insight into why the problem happens in the first place, while they gleefully eat up iMessage / Facebook Messenger / Skype / Hangouts / Whatsapp.
The real difficulty is convincing grandma that she needs to leave "AOL".
Also, running torrents is different from getting all the DNS set up and forwarding all the ports. And even then, where I live, out of the 10 or so fiber providers I can choose, I know that only 2 allow me to do anything with port 25.
It can be a Pita.
https://xmpp.net/directory.php
Similarly how it's done with mail.
This is the thing. If nobody owns it, nobody can exploit it; if nobody can exploit it, it can't get VC funding.
(We have SMTP, a must-have.)
There is no such thing as a "nice-to-have" universal protocol.
By the way, well done on sameroom. I came across your product while working on the stuff I mentioned and it looks like an incredibly useful thing. I really wish you would open source it, though. (Or at least open source some libraries for talking to the protocols you deal with. Especially Hangouts.)
We're so paranoid about getting shut down by Google (Hangouts, no API), Microsoft (Skype, no API), and Facebook (Messenger, no API) that we're not only not open sourcing any of our implementations, we're not even providing a commercial API in fear of having to deal with some form of abuse.
That said, the night is young. We hope to eventually gain enough leverage to get the big guys to listen to us.
Can I ask you some details on how you went about working with Skype and Hangouts? Did you do the reverse engineering yourself? These are protocols several popular open source projects have been trying to support for years and haven't succeeded.
Can I also ask you about your tech stack/languages you used for Sameroom?
Our magic weapon is Erlang, which is a wonderful language for working with protocols, and a wonderful runtime for working with many things happening at the same time.
The other magic weapons are the Cowboy webserver and the Gun http client -- both written by Loïc Hoguin. Loïc doesn't work for us, but we've been sponsoring him financially for over two years (https://medium.com/@abs/what-we-learned-from-sponsoring-an-o...).
Our frontend doesn't really matter as much, since it's just a dashboard, but we use TypeScript with Flux and React (it's been great).
Nobody is getting sued yet, and Pidgin supports all of them nowadays.
http://www.theverge.com/2014/4/21/5635488/msn-messenger-vs-a...
https://sfconservancy.org/copyleft-compliance/principles.htm...
Unfortunately working on GPL compliance is expensive, I would encourage anyone who cares about copyleft to support the Software Freedom Conservancy's efforts.
And all IRC implementations are "interoperable" in the sense that a single client that implements the protocol can connect to any of them, this chart seems to be padding things a lot by calling every IRC server network a "chat service". A number of them also have or have had interconnects with each other in the past.
Good luck, you are working on an important problem.
Thank you!
About getting fired - not if we sell our solution to your IT :) They might like it, actually, since they can a) provide something useful to their user base and b) get a better handle on the chat situation.
Thanks for giving it a shot, at least. It's getting to the point where if I wanted to keep in touch with most of my friends all the time, I'd need to carry two or more devices (thanks for keeping iMessage closed, Apple).
Have you written a stand alone library which communicates with skype?
We have absolutely no interest in joining that list, which unfortunately means the answer - for the time being - is no :(
We provide a ridiculously expensive way to connect, say, Slack to Skype, which is ==great for Skype==, from almost every possible angle. It means Skype users can stay on Skype instead of switching to someone else's Slack team.
Email is much better in this way, since everyone gets a copy.
With Sameroom you essentially retain the carbon copy semantics of email, but with real-time collaboration. So, I'd argue that it's great for Slack.
Our service Sameroom (https://sameroom.io) is a commercial solution to the chat incompatibility disaster, not too different from an AC adapter thingy with a bunch of different plugs, one or two per continent.
After implementing the protocols of quite a number of these systems (~20), we're seeing a scary acceleration toward further incompatibility. It's good for our business, but really pretty bad for the world.