What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 128 Stack Exchange communities.

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. All current implementations are messy, unreliable, and incomplete. And new people who want to make their own bindings must figure everything out for themselves.

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.

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.

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.


So minus the authentication issues, what do you think of the idea as a whole?

If you like the idea, how would you solve the authentication issue?

share|improve this question
4  
I really like the idea, and if I could use my IRC client to connect to the chat I may start using it (I already tried with the official browser page but I prefer my IRC client :S) –  Andreas Bonini Sep 11 '10 at 20:44
    
-1 Not because the idea is bad, but the implementation makes no sense, and seems overly complicated. –  Diago Sep 11 '10 at 21:53
    
@Diago: I've just removed the authentication part –  TheLQ Sep 11 '10 at 22:27
    
Please, no one make a idlerpg... That being said, it is amazing that SO have re invented the wheel and made an amazing fancy chat system, and now people want a way to use it in their old IRC clients! I like IRC as much as the next person, but it just seems such a waste to me! –  William Hilsum Sep 12 '10 at 3:23
3  
@Wil IRC has its shortcomings, and I sorta like the chat system. Just like Kop said, the web chat is nice but I would prefer my IRC client. –  TheLQ Sep 12 '10 at 3:45
    
Stack Overflow should reinvent the IRC client based on the goodies they've put into the online version of SO chat. I really want to see this fully integrated into my Gnome3 shell :) –  Merlin May 3 '12 at 18:46
add comment

2 Answers 2

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?

share|improve this answer
8  
+1 for every point made, but mainly "So we should also reinvent OAuth? Sorry, we're still in the process of reinventing IRC" –  Nick Craver Sep 11 '10 at 21:31
1  
"As soon as anything requires more than a browser, it's less usable for many people" I see, you just hate that its out of the browser. I would like to point to half of StackApps, where most are desktop applications. Your saying that because its out of the browser, making an API would be pointless. So then why does an SO API or StackApps even exist? –  TheLQ Sep 11 '10 at 21:31
    
Also, my stabs at authentication were trying to figure out how to use OpenID for desktop applications. They were a bunch of random attempts, but I'm not a security expert. I was just trying to acknowledge the problem of non-browser based authentication, and providing possible solutions to the problem. –  TheLQ Sep 11 '10 at 21:35
    
@TheLQ There are enough words in my answer, please don't try to put additional ones in my mouth. –  balpha Sep 11 '10 at 21:36
    
@TheLQ - When did "less usable" become "pointless"? You're putting words in @balpha's mouth, and completely missing the point of the answer. The browser comes first (and again, "first" != "only"), just as it came first before the API with the SO/SE sites themselves...I don't find this logic hard to follow. Why make an API before the primary interface is even finished? An API made right now wouldn't even fully support what they want chat in the browser to be, so why push that unfinished API as the interface for all other mediums as well? –  Nick Craver Sep 11 '10 at 21:37
    
You must of misread #2, since that was nothing close to what I was talking about. You have your OpenID, and you have your global chat password. I have no idea where you got tying it to a specific OpenID on a specific site... And yes, your current username is your, well, username, and you global chat password is your password. How that is complicated escapes me –  TheLQ Sep 11 '10 at 21:39
    
I'm going to leave authentication up to whoever writes the API. I think now its just about the idea instead of the how. –  TheLQ Sep 11 '10 at 22:29
add comment

Authentication is solved with an "API key". This is a shared secret only visible to the user and would be required, anyway, for any write aspect of the (current, non-chat) API to be implemented. (I understand write access is deferred but still intended; is that still true?)

An API key fulfills the same role as a password in traditional authentication terms, and allowing users to regenerate it at will (e.g. through account/profile settings) is the same as changing a password. Generally, API keys are a random string of ~20-30 alphanumerics intended to be copied and pasted into each app, which is then stored.

However, unlike a traditional password, an API key is not sufficient to change some account settings—most importantly for SE, they could not change OpenID accounts.

share|improve this answer
add comment

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .