As people try and make IRC and XMPP bindings for chat, they all seem to be using the same inefficient and undocumented AJAX based system to communicate to the chat server by simply reverse engineering chat with Firebug.
I give you "undocumented", but "inefficient" needs proof. Also, the people trying to make those bindings are working around the inefficient and undocumented AJAX based system. That's all they can do right now :)
All current implementations are messy, unreliable, and incomplete. And new people who want to make their own bindings must figure everything out for themselves.
"All current implementations" – I count one (maybe + and a half, if you count Greg's IRC implementation). So thanks for your praise :/
But what if chat had a streaming API, sort of like Twitter's Streaming API? This would allow people to use an actual documented and official API, as well as get an actual stream instead of AJAX which is closer to what a chat is.
What does streaming vs. polling have to do with anything? That's just the transport layer, which can be swapped pretty easily should someone prove that it's necessary. That has nothing to do with the protocol, or whether it's publicly documented or not.
Login would be the only issue, since this site is based on OpenID's instead of normal logins. Some kind of system would need to be setup to make sure user names = SO names. This is a complicated issue, but does need to be solved. From my view it looks like the only hurdle in creating any 3rd party application.
You're forgetting that SE user names don't have a uniqueness constraint.
Stab #1 to fix this (this assuming the stream is HTTP based): Each user has a custom url to stream from that contains multiple parameters that need to be correct in order for it to work. The url would at least contain a random Hash (eg bcb9eb0d98e239f08799e6f809cf9e14) and the persons user name with all spaces removed (eg JonSkeet).
This fixes what, exactly?
The issue with above is that people that monitor your connection (IT department, proxy server, virus) can impersonate you by just entering the URL.
The only way to defend yourself against someone monitoring your connection is using HTTPS. And if you have a virus (or virus-like thingadongdong) on your local machine, even that isn't going to help.
Stab #2: Every person creates a password for their chat account. Then the person simply uses that to login. This just removes any OpenID process, thus simplifying everything. While this does make sense and is much simpler to implement/use, I suspect that this will get some resistance because its not based on OpenID. However we do need to get that OpenID wasn't really meant to be used outside of the browser.
So I still use my OpenId to login to stackoverflow.com, but I have to create an extra account and password to use chat.stackoverflow.com, which will be tied to the same stackoverflow.com account, but requires a username/password combination, which isn't necessarily the same username as my stackoverflow.com username? Sounds easy enough…
Stab #3: Every app installation has a custom ID, which you explicitly activate in a browser. Then when the app phones in for the second time (the first time required activation), they get all the information on the user as well as a key to use for logging in. For future tries the app would use the random key and the username as a sort of username+password login.
The security issues occur at the very beginning. If a person was somehow able to listen in on the second login attempt, they could get the instance ID as well as the login key, then impersonate the App using all the information.
Just some thoughts.
So we should also reinvent OAuth? Sorry, we're still in the process of reinventing IRC.
We do though have to balance paranoia with usability. You could make it really secure but so annoying to use that users won't use it, app developers won't bother, and apps might just come up with workarounds. We just have to understand that were not in a browser anymore, and OpenID wasn't meant to be used outside of the browser.
Sure, there is a possibility that there will be some sort of API to access the chat. But your suggestions so far don't actually sound like anything that would not be "so annoying to use that users won't use it".
So minus the authentication issues, what do you think of the idea as a whole?
I'm missing the "What problem are you trying to solve" part.
Yes, it would be great to enable developers to create their own applications for using the SE chat in the end. Having an API (of any sort) is a good thing. And we're not saying that it's not going to happen. But:
As soon as anything requires more than a browser, it's less usable for many people. Maybe because they can't install software on their (corporate) machine, maybe because they don't want to install random software on their machine, or maybe because the don't know what "installing" even means (remember -- we're not just targetting geeks like ourselves). But everyone has a browser. So let's get everything working in the browser first, mmmkay?