Every week I have to use a Cisco jabber client, Hipchat, Slack, and Hangouts within the same company.
I know it's got less of a "cool" factor because it wasn't invented last week, but I soooo wish everyone would just use IRC. Use irccloud if you want some nice apps and picture embedding.
Is it possible to get what Slack provides using IRC? I mean the whole package, not just the text chat. Consider enterprise-friendliness, excellent mobile clients, zero-setup required (no separate keep-you-online relays), really easy integrations, etc.? We are adopting Slack because it's great and I'd have loved to make a case for IRC but I wouldn't know what server to recommend (we don't really want to install it, but we don't want to use a public server), where I can get commercial support, if there's a nice client (like irccloud is) for mobiles - there's a long list, unfortunately.
Also in-client searchable archives, media handling, history editing. All require going outside the IRC protocols.
IRC was designed by hackers, for hackers and it shows. Twenty years ago, IRC was my talk destination of choice and I operated a server within a major IRC network; these days my startup uses Slack which I determined to be the "least irritating" of the 21st century options.
I had high hopes for Google Wave but it was sadly stillborn.
Much of that can be had with a IRC bot. That doesn't include media handling, but you could do search via 1-on-1 /msg (query) with a bot. Then it'd truly be "in client" search.
Most would probably prefer a web ui, with search -- but recording chat could still be done via a bot.
I wouldn't say you could get most of the whole slack experience with just IRC, and you'd probably have to do some work (if only configuring channels/bots/find a web ui etc).
This doesn't resolve the multifarious issues with identity, reliability, scalability, federation, standardisation &c &c that further rule IRC out from being the universal panacea.
I stopped reading when the charter said "we are not working on the server protocol". The server protocol is the limiting factor in IRC's architecture.
My interest is in federated, reliable, ad-hoc messaging and IRC's acyclic forwarding graph and lack of any inherent identity model make that impossible.
It depends on the context. You can't federate with Google, Microsoft, Facebook anyway -- and you won't convert the world to use your favourite new protocol (most likely).
So that just leaves you with an easier problem: how can I host conversations etc for my team/org/my friends? And I think a single, isolated irc server should work fine for that use case, and work fine with many different irc clients?
So no, it's not a universial solution -- I just think it's strange when people bring up slack as somehow "better". Sure it's "better" in that it's a product with backing from some fine people -- but if you wanted a solution based on open standard, Free code that you could self-host without worrying about license costs etc ... then a battle-tested IRC server still seems like a half-decent option?
Or put it a different way: if you have 100s of users, could you get many of the features with IRC, and some bots? (Or maybe a slightly tweaked IRC server etc etc)?
[ed: Not that I claim there aren't problems with IRC -- and I've yet to run a personal ircd, so I don't know a) how much work it is to force TLS+SASL[1] and disable plain IRC, or b) if there are other solutions that might be better, that are available right now.
That is not an "easier problem" - that is repeating the problem: yet another venue/client/service we all have to be logged into to find one another.
Moreover, I'm really not interested in spending any time whatsoever on configuring and maintaining an IRC server and a fleet of bots, nor on teaching non-technical users in how to use the resulting heath-robinson system. Really, no. A world of no. I have run both a private IRC service and a public node of a very large network. It's a huge time sink. I've moved on.
As I see it, the only problem in this domain worth burning hours on is developing a protocol (and interoperable implementations thereof) that achieves everything the likes of Slack and Hipchat can do, only in a decentralized and federated manner.
> that is repeating the problem: yet another venue/client/service we all have to be logged into to find one another.
I'm not sure how you can create a new venue without creating a new venue? Perhaps have Google/Facebook/Microsoft/BigCorp create one for you, and the use that? But none of the big players appear to care a whit about facilitating a distributed, self-hosted, open Internet, so that is not going to happen?
> As I see it, the only problem in this domain worth burning hours on is developing a protocol (and interoperable implementations thereof) that achieves everything the likes of Slack and Hipchat can do, only in a decentralized and federated manner.
Any particular reason why you think IRC is inherently not a good building block for such a set of protocols/implementations? I'm not talking about IRC with legacy client support, I'm talking about a system that explicitly breaks comparability with legacy IRC, but still try to build on the years of experience and battle-testing IRC has.
You might be right that it's better to burn IRC to the ground, of course. My takeaway (as an observer, not a server operator in the trenches) is that one takeaway from XMPP/IRC is that:
1) We need authentication of users
2) We need authentication of servers
3) Today, we have no need of plain-text; encrypt and authenticate, or go home.
It appears that 1+3 leaves us with TLS-only, SASL auth if we go the IRC route. For 2) I suppose manual mediation of some kind (eg: server certs with Trust-on-first-Use, possibly a community blacklist?). I'm not sure if this would work, but on the surface it would appear to enable less spam and better security than email currently does.
And it should be much easier to strip down/adapt existing clients and servers than to build an entire new stack?
All that said, it might very well be that IRC server-server federation is hopelessly broken, and there's no hope.
Perhaps some kind of server-auth/community-web-of-trust framework on top of XMPP federation would make more sense?
But it's not possible to get what you're asking without breaking the IRC protocol - it's not easily extended and the formatting rules are icky mIRC crap.
The trick with capabilities is you need them to be reasonably standard. Which means the go to IRCv3 server should ship with them turned on, and the reference client should be capable of using them.
I didn't make the decision. Slack started to appear and I didn't know that IRCCloud had apps (which seem to have great reviews). If I had known, I would have suggested it as an alternative. As it was, I just kept quiet as Slack seemed great - even better than HipChat, which I used to use for the same purpose.
Perhaps IRCCloud could be sold as a rebranded Enterprise app as an alternative to Slack? I'd love to see some competition as it looks like only HipChat and Slack are getting talked about.
That sounds like a problem with the company. I can understand Slack and Hangouts (at least until Slack adds voice chat), but all that other stuff sounds like poor organization on the company's part.
What I posted in another thread still stands - https://news.ycombinator.com/item?id=10256943. Things were better when everything was brought under one client. I know iMessage is almost impossible to reverse-engineer (due to Apple kicking non-iClients off) but I wish there was more effort going into reversing Hangouts. Someone's emulated the JS client from GMail but that's about as far as it's got
IRC's lack of scrollback alone kills it for these considerations, unfortunately. If there's an incident or discussion in progress and you only join the room partway through you have no way of catching up to speed.
I know it's got less of a "cool" factor because it wasn't invented last week, but I soooo wish everyone would just use IRC. Use irccloud if you want some nice apps and picture embedding.