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.
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.
It looks like an interesting platform, but I was a bit surprised by what I found at:
https://developer.actor.im/docs/encryption
"MTProto v2 Rev3 enables encryption support to replace or enchanse TLS one." So far so good - here's someone that's built on top of NaCl and built a legacy-free encryption system on top of well tested, known primitives, I thought.
But: "Actor encrypts message with US encryption and then again encrypt with Russian encryption that in result guarantee absolute encryption streight" (sic).
Uh. This sounds like applying a "political" reasoning to layering security: AES might be backdoored by NSA, GOST(?) might be backdoored by the FSB -- but using both, only double-agents will be able to foil our encryption!
While the truth is probably that you're know vulnerable to buffer overflows or other more mundane software errors in the now double-sized encryption code -- and get none of the (potential) benefits of a clean, modern architecture on top of just NaCl?
In addition, it appears you also use curve25591, possibly an implementation derived from NaCl:
https://developer.actor.im/docs/securing-server
"For secure communications Actor Server have to be configured with Curve25519 keys. To generate them, use actor-cli util:"
So that's three codebases worth of bugs, rather than one. Any plan to simplify this part?
US-based encryption is taken directly from BouncyCastle, time-proven library for Java. Russian implementation can contain bugs, yes, but i can guarantee that there are no timing or overflow attacks possible. Even when we will have broken russian layer, us layer will be safe. Also we are on the way to make everything verified by 3rd parties and seal cryptography parts.
For key exchange we use curve25519. Implementation is taken directly from Signal and this app is trusted by majority.
We
[ed: Oh, and here I go, proving that non-cryptographer should be careful about what they say wrt encryption, apparently AES isn't a feistel cipher? http://crypto.stackexchange.com/questions/10605/why-is-aes-n... ]
> Also Instead of using N code bases (one for each platform) we reduce it's amount by conversing sources from java to other languages for every platform.
It's a pretty strong claim to say that you take three different encryption primitives, implemented by other people in java, and translate them to other languages -- and can also be sure there are no timing attacks? (Or oracles, or resulting errors)?
Surely it would be easier to stick to as few lines and layers as possible if you want it to be easy(er) to audit?
(So simple there's obviously no mistakes, vs so complex there's no obvious mistakes and all that).
It's a bit like saying you made a boat out of wood for buoyancy and filled it with sand in case the wood catches fire. Sure, a plank of wood doesn't sink, but too much sand can make it sink, and sand won't be of much help if there is a fire. A wooden boat is better than one filled with sand.
I'm not sure how the fact that the boat was made in Java is relevant, either. If anything, it makes it harder to prove that there is no timing attack, as the JIT could do unexpected things, long after the program has started.
Even federated networks eventually gravitate towards a large degree of centralization once the tech becomes mainstream (see email). If any servers are used at all in a privacy-minded app, they need to be zero-knowledge as far as I'm concerned, for actual user data at the very least, if not metadata as well (I realize the latter is an unsolved problem).
How does Actor handle user data and message storage?
At least that's how I read Slack's security page (https://slack.com/security-practices) that only talks about "Data Encryption In-Transit" (i.e. server-to-client) and Mattermost's About page (https://about.mattermost.com/) that also talks (only) about encrypted "client-server data transmission".
I do agree that end-to-end encryption is important, but at least Matrix is aware of this and they are working on it (https://matrix.org/jira/browse/SPEC-162).
I definitely appreciate that the Matrix team is aware of and actively working on E2E encryption, but it doesn't change my stance that Matrix is not a feasible building block for privacy-minded apps until that work is complete.
Now, a more interesting privacy concern is that Matrix doesn't and can't protect metadata currently - see https://matrix.org/~matthew/2015-06-26%20Matrix%20Jardin%20E... for details. So if you want both encrypted contents as well as obfuscated metadata, go check out Ricochet or Vuvuzela or Pond or something for now :)
For now, building a great federated chat protocol that allows users to fully control their own data should take priority over just about everything else, because once users are in control of their own data, they're no longer locked to a single platform. So if another protocol comes along that does everything Matrix gets right and adds metadata protection, users can simply export their data and import it to the next great app/protocol (which is hopefully also federated). Until we have a great federated protocol that everybody is using, the friction associated with moving between chat apps/protocols is going to continuously inhibit real innovation in the messaging apps space by favoring apps that stand on the strength of their network effects over apps that stand on their own merits.
On the topic of fully distributed apps, I really like what replikativ is doing in this space:
https://github.com/replikativ/replikativ
It's a CRDT-based data replication library for building fully distributed applications. They envision replikativ being used as an open data exchange whereby users fully control their own data, and can specify any number of applications to have access to that data, instead of the status quo where user data is kept in closed, per-application silos. Their README has a much more comprehensive overview of the library and their vision.
I'm hoping it's still on some sort of roadmap.
Also we had Tor-enabled client, but Tor is not suitable for mobile apps.
How do other servers know how to reach me?
The IRC protocol is old. It predates HTTP. Some things are possible in theory, but pointless if no client supports them.
Look into ircv3 (http://ircv3.net/), they're writing new specs for the IRC protocol to build exactly what you're talking about. It's very promising, although IMHO too little, too late - Matrix looks like it's going to take the crown eventually.
If you have an old, flat IRC client, it's ugly but you can figure it out. If you have a supported client you get a nice UI?
IRCv3 fixes all that.
This is a problem bouncers are already solving best they can, and it still sucks. It's not good enough to compete with slack.
I didn't say anything about competing with slack.
The tech is all there. It just sucks to set it up yourself and should just work out of the box.
"Oh, Johnson isn't online? better send him an email. /message acmebot email [email protected] Get your ass to mars!" chat bot sees the command and sends him the email.
Sorry if I'm coming off as cynical it's just that I see a trend of the entire community trying to fix problems that aren't real problems.
You could argue that some of the characteristics we find in chat are not useful, counter productive, etc. And there is probably some truth to that. But that is a different argument than what you made.
Chats have an important place because they allow us to say small things, quickly. What you suggest will result in no viable chat for mobiles, only emails. We can probably make a chat app that looks and feels like whatsapp but actually sends an email for every message. Dunno what problems this might have.
You want to pick and choose your UI? That is an anti-feature. One user sends an image and the other cannot display it because he uses a terminal client. One user sends an emoji, another client only displays a box, because he has no glyph in his font. This is already a problem with XMPP. It has lots of nice features, but each requires server and client to support it. There is no "Full XMPP" label.
And since you prominently talk about the protocol: XMPP probably has all the features one needs. Why hasn't it won yet? Because the complexity of all server-client combinations makes a good user experience too hard.
What is the problem with using different clients/networks for different groups? Why do you want to mix work and private groups into the same app? What does matter (especially for web apps) is a unified authentication scheme (Mozilla Persona would be my favorite), so I can quickly switch between them and do not need lots of accounts. Thus: Federated accounts, but diverse chat solutions.
(disclaimer: I slightly exaggerated to play devil's advocate)
That argument is like saying we should only have one HTML browser because text-based browsers like w3m could exist.
And "one user sends an emoji, another client only displays a box, because he has no glyph in his font" is an issue between different operating systems. Even in a non-federated system like Slack I used to get emojis from people using iOS8 that don't display properly.
What about Spectrum http://spectrum.im/ ? I am successfully using Spectrum as gateway to Skype (except groupchats ATM, some bugfixing pending) and IRC from my XMPP client apps.
What about XMPP in the whole? It looked depressing few years ago, but times have changed, I can help you to catch up with nice novelties.
I'm personally working on Movim, a nice-looking "Social-IM" client fully based on XMPP (https://movim.eu/). The main goal of the project is to show that we have now all the tools to build a decentralized, standard and universal IM (and also social !) network without reinventing the wheel again and again.
You can have a look at our latest release-note as well https://pod.movim.eu/?node/pubsub.movim.eu/Movim/f5f883e3122... (this blog post has been published/edited using Movim and XMPP ;)).
And Movim is also compatible with Spectrum to offer interconnection with other networks ;)
Can you recommend a few? I haven't looked into XMPP in detail for a while, because the clients I've been using are "good enough and I didn't bother with mobile), but it seems like I'm missing out on good things ;)
For the desktop there is no real "modern" client yet, unfortunately. But I've ported Movim using Electron :) There is already a Ubuntu/Debian version and the package is here https://github.com/edhelas/movim_electron.
I'm curious though.
What is it about IRC that makes it not a good choice? It seems to me that the biggest issue non-nerds care about is the user experience. And I feel that if people wanted to, that could be fixed. And if we really wanted to, we could extend IRC to do what we want and deal with its shortcomings.
I use a nice web gateway (kiwi) on top of an IRC channel for my student office hours and it's easy. They just supply a username and log in. No software to install, the UI looks nice, and students don't have to sign up for anything.
If I had the resources and the money, I'd focus on a good modern IRC client and server.
Am I wrong?
Yes and no. Setting up an IRC server is hard. Pretty much all IRC servers use arcane settings and configuration formats. I run an Inspircd and Hybrid servers, and for people who aren't used to it, it's really daunting compared to setting up something like prosody.
Services on top like Kiwi are nice. I run Shout IRC which is beautiful and slack-like, but again requires passenger and node to work, so lots of moving parts just for a web-ui.
Having said that, all of this is perfectly doable, it's just not so easy if you're used to dealing with something lightweight and a little php on top.
Seems like a quick script would set all this up for us :D
your use case is very different, and i wouldn't expect any pay-for-chat service to make any sense for it
Although I take issue with "when chat is down your business is at risk."
Pick up a phone. Use Skype. Send email.
Business was done for thousands of years before chat apps. :D
It's perfectly possible to pivot your sales funnel, but it's not something you can do in two hours whilst the chat server's down.
If you rely on a third party for business, you need to plan for it.
The rule always applies: You will pay now or you will pay later.
[1] https://matrix.org/docs/projects/as/rocket-chat-federation.h... [2] https://matrix.org
XMPP seems to be rather dead, for various reasons, and no real contender for a replacement has sprung up. I guess there always is, and always will be IRC…
It's a real damn shame because XMPP is pretty awesome. It's open for one, can be made super secure with OTR (client-2-client encrypted chats), has numerous protocols and implementations for stuff as diverse as message archiving, Audio/Video signalling, file transfer, chat (of course), presence and an absolute boat load of other stuff: http://xmpp.org/extensions/index.html.
There are two big issues as far as I can see with XMPP which really hurt it:
1. XMPP was incredibly poor at handling high latency, intermittent network connections (like cellular). Connections would time out, reconnections would take ages and all in all it really hammered battery life. As a consequence mobile app developers moved very quickly onto REST/JSON (yes there was XEP-0198 - Stream Management - but implementations of it were thin on the ground and even then it wasn't perfect).
2. There just isn't any interest amongst new developers or newer projects at least in an XML based chat protocol when REST/JSON is so attractive. Anyone who has had to write a god damned XML parser knows what I'm talking about.
Things are a whole lot better now. XMPP has fixed a lot of session and battery life issues since then but to be honest I'm just not feeling it when I go to XMPP meetups. Feel like I'm attending a wake for an old friend and it really is sad because if there was ever gonna be one protocol to rule them all XMPP was far and away the best candidate.
Who knows, a couple years from now large companies and governments might finally wake up to the fact that they have 100 different sucky (probably) REST based APIs amongst all their apps which are not remotely compatible and offer poor archiving and retrieval (like they did in the 90s when they forced Microsoft to open up their Office document format). XMPP might come to the fore again then (wouldn't put money on it though). More likely something similar (and not XML based) will take its place.
It's anyone's guess really, suffice to say the present situation does feel like a complete and utter mess and will really start biting us in the ass when compliance asks 'how do I archive/retrieve this pot pourri of data'.
What are your thoughts on Matrix?
Reminds me of what the Layer guys were trying to do (at least in their initial mission statement). https://layer.com
Pros of Matrix are that it looks like they have full chat support, are working on adding end to end encryption, and of course have federation which is super important for interoperability.
Only concerns with Matrix are that I don't see any large projects or companies spearheading it. Also seem resource constrained. For example it looks like they planned on rewriting their existing basic server side app in C and then ended up just writing a proxy. So clearly it's still a small project. Also see verbs in their URIs...I'm not super up to date on REST best practices but isn't that a no-no?
Anyways early days - and it's easy to nit pick. Matrix certainly looks compelling enough that I'd be interested in trying it and seeing them succeed. God knows we need something like it and soon.
In terms of resources: a bunch of us are paid by our dayjobs to work on Matrix fulltime, and meanwhile there's a pretty active wider community surrounding the project. However, the 'core' project of building a spec, reference server, reference+glossy web and native ios/android clients, as well as loads of bridges really is a significant amount of work, and we're going as fast as we can. https://www.openhub.net/p/matrixdotorg gives an idea of progress (although only seems to spider a few of the core projects). I wouldn't really call Matrix a 'small' project :)
In an ideal world we'd stop the world and take N months to entirely rewrite Synapse (~40KLOC of rather dense Python/Twisted) to Go/Rust/C++/Java/Node/whatever, but that's N months we don't have right now. It's not really the lack of resource, but the fact that the window is rapidly closing to provide an interoperable fabric between all of these proprietary communication apps (be they open source or commercial licensed), and we want to get a stable solution out there before it's too late and we end up in a world where the silos have won (c.f. social networks).
Hence the pragmatic decision to do an incremental migration from Synapse to Dendron, which is our next-gen homeserver written in Go (not C). Dendron is indeed mainly 'just' a proxy for now, but this is actually incredibly cool as it can act as a Matrix-aware loadbalancer across multiple Synapse backends. The horizontal scalability and HA this gives is a huge deal. Meanwhile, it gives us a way to gradually migrate endpoints from Synapse into Dendron and provide a way to replace the Synapse codebase without having to do a stop-the-world rewrite. Personally, I think this pragmatism is ftw.
In terms of verbs in URIs... we've been pragmatic rather than religious about REST naming conventions; if someone can give concrete reasons to rename endpoints before we freeze the spec, please tell us! Bugs to http://matrix.org/jira/browse/SPEC and PRs to http://github.com/matrix-org/matrix-doc please ;)
And whatever, please do come hang out on #matrix:matrix.org and #matrix-dev:matrix.org eitherway if you want to find out more and help us escape beta!
Well, it failed to be the preferred solution for its problem domain, and is universally ignored by big players.
Google also killed Talk in favor of Hangouts (and the later doesn't talk to XMPP).
Google Talk, Facebook Chat, Origin (EA), Playstation, Cisco WebEx, WhatsApp all use/used XMPP for instant messaging.
That sounds like it's the preferred solution for realtime messaging, with vendor lock-in and NIH syndrome decisions being the major reasons that it isn't used in even more situations.
> and is universally ignored by big players.
As evidenced by the above list of major deployments, it is absolutely not "universally ignored". The problem (as someone else pointed out) is that for many of the "big players" a federated protocol is not what they want, so they don't allow federation, and don't allow/publicise the use of standard XMPP clients.
> Google also killed Talk in favor of Hangouts (and the later doesn't talk to XMPP).
This is a reason to stop using Google services, not a reason to claim XMPP is ill-suited to the task at hand.
For example, suppose you want to send an IM to your friend. You believe in XMPP or some other open/federated protocol, but you don't know which friends use the protocol. Piggyback off email. Note that identities are backed by email. Also, if any identity-providers refuse to join the federation, then route through a trusted fallback service (Trent.com). Pseudocode:
function send_im(toEmailAddr, messageText) { // See if the user's domain already supports OpenChatProto. if (nslookup(toEmailAddr.hostname, 'SRV', 'OpenChatProto')) return OpenChatProto.deliver(toEmailAdrr, messageText);
// If user's domain doesn't support it, see if the user has
// registered+authenticated with a trusted third-party.
var proxyAddr = http.get('https://trent.com/proxyAddr?email='+toEmailAddr + authCode);
if (proxyAddr) {
return OpenChatProto.deliver(proxyAddr, messageText);
}
// If the user doesn't exist in OpenChatProto, then
// fallback to email.
var emailText
= messageText
+ "To continue this discussion in real-time chat, go to:"
+ "https://trent.com/setup?email=" + toEmailAddr + authCode
+ "To block messages from this person, go to:"
+ "https://trent.com/optout?email=" + toEmailAddr + senderEmail + authCode
+ "To opt-out of all messages, go to:"
+ "https://trent.com/optout?email=" + toEmailAddr + authCode
Email.deliver(toEmailAddr, emailText);Note: It's most efficient if members of the federation agree on the identity of trent.com, but it's not required. Any outbound MTA could use a different Trent, but that fragments the brand and identity databases.
This feels pretty obvious, so maybe it's already being done or I'm missing something...
XMPP is very much alive in large businesses, especially for system to system interop, but as far as client to server goes I don't see a compelling XMPP client - where's voice, video, chat archiving for example? Compare any XMPP client to Skype for instance and they're not even remotely close.
This requires a central server though. This is more a function of the service providing XMPP to you than the client. If you want the functionality on the client, it presumably requires some sort of interop between client and server that I'm not sure it part of the XMPP spec.
The problem is, there are far too damn many XMPP extensions and too few of them see any kind of real adoption.
XEP-0313 is a modern replacement, focusing on just the things that people actually need. It's implemented in many servers and clients already (see https://www.zash.se/mam.html ). It's still under development, but it's already in active use by many people.
This is why nobody wants to touch XMPP with a ten-foot pole.
Honestly, there's some days I wonder if there's any way to win.
Secondly regarding XEP-0136 support in OF. I did state that Openfire has only recently had 'XEP-0136 implemented across the board'.
Whilst the Open Archive plugin which provided support is a fine piece of work it was an incomplete implementation with only 1-to-1 chats (no group chat support).
I worked on merging the monitoring and open archive plugins to provide support for both MUC and 1-to-1 using XEP-0136. That work was only fully finished a couple years ago in 2013 so think my comment's still accurate.
And ejabberd of course (powering WhatsApp): https://github.com/processone/ejabberd
You'll see that on the server side at least XMPP is very well catered for.
Deal breaker against it (depending on your use case) is lack of support for multiple domains. It can only handle one per deployment.
It also does need at least 512MB RAM which rules it out on embedded devices.
Now we have more bandwidth, and sending XMPP as a server is negligible.
I just would prefer JSON to XML. :-)
Semi-related:
IRCv3 is an advance in the right direction, but I wish they would make huge breaking changes now - instead of introducing new standards to manage a migration to "later IRC".
Two things I want to see are IRC encoded as JSON, and TLS-only servers in the standard as a requirement. They added message tags which I think just makes IRC ridiculous to parse - if the objective is to extend IRC and add ancillary data to the message they should just use JSON already. I think it's a bad move to allow some intermittent migration path if we all know the end-game is IRC encoded as JSON. It'd be dirt-simple to autodetect if you're receiving JSON or traditional IRC, too. You don't need a CAP exchange to tell you "oh look, it's gonna be fucking json, m8".
An example a feature IRC would need to change for is the ability to edit messages. Slack lets you go back and correct already-submitted messages. You don't have this ability in IRC - and there are ethical reasons to not support it. Personally I'd be in favor of IRC having a command for editing messages, and then clients keeping the entire history of edited messages - so you can always see the original. It's not like the server can take that data back - it's jsut assumed clients would show only the latest, revised version of a message.
I could also see having the IRC server support a virtual DCC user to upload files to - so then you could emulate file attachments like you have on Slack. This is something that can be abused though - file uploads are a security and DoS concern. Slack can support certain things because the infrastructure is paid for - with IRC networks it's largely a "free" operation.
In the past I've made a "Hookbot" that triggers and POSTs to outside services just like Slack. On some IRC networks there are network-vetted bots you can request in your channel to configure and make use of. You can largely support everything Slack does in existing IRC, we just needs standards to add some coherency and expectations for developers/users.
UX does matter, I completely agree with you - IRC needs to change minimally to support those Slack-like features, though. Clients need to change. Most of the draw of Slack is embedding linked items in the chat for convenient viewing. Even icky Mibbit does that :p
Think of a bar that lets you bring drinks from other bars. It doesnt have good prospects.
https://en.wikipedia.org/wiki/Internet_Relay_Chat
Laziness.
JSON in, JSON out. HTTP codes tell you what response you got. TLS on an https connection for secure communications. WebRTC for voice calls, and you just query the API for the signaling server to use.
Gee, wouldn't it be nice if you could pick and choose your UI? Pick and choose your "integrations", your "plugins", your client, etc without having to lose your entire userbase, history, contacts?
Some sort of open protocol.
Urgh, I've been working on this lately and the entire field is depressing. Between one side that doesn't understand the legitimate need for open protocols, and another side that doesn't understand why IRC isn't the end-all-be-all of group chat (and why UX matters), it's just people talking past each other.
Every new attempt at making "the slack killer" makes this problem worse, because it comes with its own protocol. Its own users. Etc.
PS: If somebody has free time to work on an open source multi-protocol group chat gateway, email me, I have something started.