Will there be any way of accessing the chat over IRC?
As beautiful ajax interfaces are ... IRC is still #1 for chats.
Will there be any way of accessing the chat over IRC?
As beautiful ajax interfaces are ... IRC is still #1 for chats.
update: initial author isn't working on this anymore (last commit was 2010)
As Andy E's head mentioned, I've started to create an IRC interface for the SO chat. The current state of the code is on Github: http://github.com/ghewgill/soirc
It's all ugly, nascent, fragile code right now but I expect that will improve in time.
The chat isn't based on IRC, so I think this is unlikely. It would have been possible to build that kind of interface on top of IRC, but I think the team did a very good job of building it from scratch.
Greg Hewgill is looking for some help putting together an unofficial IRC interface for the chat.
yay it works, typing this from a hacked-together irc interface now. :)
ACTION whistles innocently
this is a program you run on your local machine which acts as an irc server
you connect your client to localhost on its port and away you go
http://chat.meta.stackoverflow.com/chats/message/47605?offset=60
I love IRC, but I think the ship has sailed on this one. The problem with IRC as an add-on is the authentication problem. This chat system is inherently based on authenticated users with known reputations.
You can't really get that connected to IRC meaningfully unless you run your own customized IRC server so you can merge the IRC account (and you'd incur the cost of supporting username:password logins).
Implementing it as a proxy you run on your own machine (where you could provide your ID to the proxy) seems like the only choice, with custom /commands for the special features of StackOverflow chat (starring, flagging, editing ...)
I'm not sure an IRC bridge is appropriate for SO chat... authentication would be one issue (how do you login with OpenID to IRC?), and another issue would be ensuring appropriate connectivity between the IRC bridge and the AJAX interface's backend, which is probably not inherently made for long-running TCP connections.