Why do we have our own separate chat system rather than going with IRC? What does the current chat client offer that IRC can't and what benefits could this choice have in the future?
First of all, you're comparing apples to biology books. IRC is a protocol. So the question
What does the current chat client offer that IRC can't[...]?
is like saying
What does Facebook offer that FTP can't?
That said, there are many reasons why the Stack Overflow chat infrastructure is not based on IRC. Here are the (in my view) most important ones:
1. The technology stack
Almost all of Stack Overflow's / Stack Exchange's technology runs on Windows, IIS, and ASP.NET MVC. Now, anyone can think that this is an inferior technology, evil proprietarism, or waste of money – it doesn't matter what they think, because the bottom line is: It is how it is.
And when a company offers a product, they have to support it. And for obvious reasons, almost all Stack Overflow's developers have long-time experience with this stack (myself being an exception). So building the product with the same technology makes sense.
Of course you can throw in a "best tool for the job" argument here, but matter of fact is: "the job" is not only "offer a chat service", but "offer a chat service that integrates well into the rest of the company's toolchain/development process/support mechanisms/infrastructure".
There are many features that we want to have in the Stack Overflow chat that are not (or not without a big hassle) supported by IRC. rchern has named some of them in her answer. Others include
- good persistence of data, including searchability (integrated and through search engines),
- supporting ways to highlight important (in whatever meaning of the word) parts, to assist people in finding their way around without having to read through 24 hours of chit-chat – the SNR is naturally very low in realtime chat,
- permalinking single messages or groups of messages to easily quote important content somewhere else,
- sustainable community moderation,
3. Parent site integration
This somewhat ties in with 2), but is important enough to be its own point.
The Stack Overflow chat is not just a stand-alone application. It is intended to be supplemental to Stack Overflow itself.
- Participation in the chat requires some participation on the parent site.
- User authentication is 100% integrated with the parent site (in other words, at the very least you'd have to teach
NickServeto understand OpenId).
- Chat replies appear in the StackExchange™ MultiCollider SuperDropdown™.
- Talking about questions on the parent site is an integral part.
4. End user accessibility
Please don't tell me IRC is good at making it easy for people to jump in and start chatting. Because it's not.
To somewhat effectively (let alone efficiently) use IRC, you have to get comfortable with a bunch of commands and conventions. Of course there are clients that assist in hiding some of the complexity, but in the end, if you don't have an at least basic understanding of the underlying technology, it's pretty easy to misuse IRC.
Let me quote Steve Krug here.*
Faced with any sort of technology, very few people take the time to read instructions. Instead, we forge ahead and muddle through, making up our own vaguely plausible stories about what we're doing and why it works.
Why does this happen?
It's not important to us. For most of us, it doesn't matter to us whether we understand how things work, as long as we can use them. It's not for lack of intelligence, but for lack of caring. In the great scheme of things, it's just not important to us.
*Steve Krug, Don't Make Me Think, 2nd ed., New Riders, pages 26 & 28
When a user comes to the Stack Overflow chat, what they want to do is chat, period.
This gets even more important as the Stack Exchange network expands outside the traditional technology geek area. What percentage of cooking / biking / saltwater aquarium enthusiasts have ever even heard of IRC?
But even within the geek/programmer community, the whole "They like to figure out how it works and have no problem with digging for results" idea is a myth in my experience. Even we want to get things done. And I think that the overall response to the launch of the Stack Overflow chat (both in terms of sheer numbers and in terms of the very positive reactions) is another proof of this.
I may not agree with the choice necessarily and I won't get into that, but this seems to be turning into oh, oh, that says irc...downvote!! despite it being a perfectly valid question, so here's a couple things. They each have their own strengths and weaknesses.
The chat system is tied to your site account. You must have a certain amount of rep on the parent site in order to talk in the chat. If you post spam or offensive things in chat, it can be removed and that may come with a rep penalty.
There is support for one-boxing, which means that if you paste in an a link to a supported url: image, amazon link, twitter status, etc, then the chat will display the actual content rather than just the link.
Content can be starred, and these starred items can be viewed separately.
Personal opinions on how these things could be handled not included.
Disclaimer : I still didn't use the chat system, so this is only reflecting my point of view.
As flexible as IRC could be, doesn't offer modern perks of modern community chat service :
- Auth is done through third party services Nickserv which provide limited auth,
- Providing alternative "official" ways to connect is more difficult to support ( must provide explanation for 3rd party client to connect)
- Still prone to netsplit, which in today's age is quite frustrating for people who don't know about this.
- IRC protocol support for client is still dodgy for "extensions" such as unicode (yeah who cares about these foreigners), and formatting (hey I also want a rainbow writing).
- Unsupported Third party client is a security issue for the users as it has always been a habit to IRC users to ask a newcomers to execute more or less harmful command ( from "/quit" to more harmful command, either on channels or in private messaging ).
- IRC still hold a very bad images of being too "open" for people to allow harmful activities (Impersonation would be a very good one ).
- Command are not obvious, and command that would apply for stackexchange would be less obvious.
As bad as it could be to "reinvent" the wheel against using a proven protocol: Provide a web interface that is familiar to user (integrated), instead of try to integrate a web interface based on protocol limitations :
- Abilities for users to moderate their peers/response with votes
- Seamlessly integrated stackexchange features in the chat interface.
- Administration would require a skillset that the stackexhange staff might not have.
- Pushing a limited chat and adding features afterward to it looks way better than providing a limiting subset of features of an existing protocol then trying to implement extra features later.
- Others stuffs I cannot think of.
Plus pushing an all microsoft solution looks very good for MSFT, so they would be more willing to support the website (technically or financially).
But my emphasis would be security. IRC still reeks too much "social engineering".
Two good reasons not mentioned so far.
One: web-based chat is supported out of the box by all modern browsers. IRC requires you to install additional software, certainly on Windows at least. (On my Windows 7 machine, neither IE nor Firefox nor Google Chrome recognise irc:// links.)
Two: web-based chat operates by HTTP through port 80. IRC requires other ports, which are much more likely to be blocked by corporate firewalls.
Wow, you all REALLY hated this. Impressive negative response! This was just my opinion. My point was that some people expressed interested in IRC -- sorry for offending you all :(.
(This should be a comment on balpha's answer, but it's too long. So I'm posting it as a response instead.)
1: Technology Stack
There are a few good points here, but basically, there is no reason you cannot write an IRC server in pure ASP.NET MVC, or whatever. There's no rule that you have to use some IRC server in another language. I don't think this really counts as an issue.
Again, with your custom C# IRC server, many of these become trivial to implement as well, making logs available and searchable is just a few extra steps. Once you re-create the chat.stackoverflow.com website -- even as just an enhanced IRC client -- you can do the same integration with the website.
3: Parent Site Integration
As the post says, you could just have NickServ use OpenID. At this point, it's not that hard. Again, all of this can have a great UI on the client-side webirc client at chat.stackoverflow.com, and a much poorer one on a standard IRC client. That's fine. The people who are using IRC to connect to this are the ones who can figure it out.
4: End User Accessibility
Similarly, the chat.stackoverflow.com IRC "client" can create that nice experience. No more confusing commands, it offers a easy-to-use, well-designed way to get chatting quickly and easily. No hassle. The only difference anyone would notice using this type of setup would be that you can connect using your favorite IRC client.
And that would get you at least one more person idling and answering questions.