back
41 comments
The Twitter people continuously surprise me with their incompetence.

And yet, we keep using the service. Hrm.

I think it's pretty clear that there's someone high up in the food chain making executive decisions based on personal technical skills they're not competent with. More hirings etc doesn't seem to be having the right effect. I think you need meddling to make things this bad.
And yet, we keep using the service. Hrm.

I like http://identi.ca/, an implementation of http://status.net/ .

You mean an installation of status.net.
The easy answer to this is to just stop developing for their platform.
Personally I think I heard the phrase "don't be dependent on other companies' platforms" enough times to feel it in my bones. Some people obviously didn't.

On the other hand, that's morally draining - particularly when one works on something that's open source.

This HN submission suggests that's exactly what is happening: http://news.ycombinator.com/item?id=1681844
As with all easy answers, it ain't necessarily that simple. What if you have a startup that's based on the Twitter API? Where do you go? Plurk? Facebook has its own API issues, of course.
I think it is that simple. You don't build your startup solely on a free service that someone else has complete control of.
You don't build your startup solely on a free service that someone else has complete control of.

Sound advice. When a lot of these startups were conceived, that wasn't as obvious as it seems now.

That's been obvious since well before Twitter was created.
Surprised at the amount of agreement with this article, and the cries of "incompetence".

ISTM in a desktop app context, the consumer key/secret combination effectively becomes a complicated equivalent to your browser's "User Agent" string and yes, only slightly more difficult to spoof.

So what Twitter is asking for is that in order to authenticate a user (with additional credentials) you give them a valid "user agent" that was assigned by Twitter. This at least allows them to understand, when they get traffic, who wrote the app that's sending it. It's obviously not perfect in a desktop case but then neither is user agent - but there is no perfect solution for the desktop case, and Twitter's choice allows them use a consistent mechanism for client and server apps.

(Edit: the OA responds below and says I'm wrong about this part. I'll take his word for it.) I suspect the OA's problem is more with being a) asked to do this nasty complicated Oauth thing and b) with the idea of Twitter wanting to know who he is - and he'd rather they just let him keep on persisting user's twitter creds himself. Conflating this consumer key with DRM is a bit of a giveaway.

(Updated: The important point here is that the author's app is open-source and he chose to distribute the keys with the source code, rather than require each person who builds it from source to get their own API keys. I think Twitter's position - that the author should not have done this - is completely reasonable.)

> So what Twitter is asking for is that in order to authenticate a user (with additional credentials) you give them a valid "user agent" that was assigned by Twitter.

No. What Twitter is asking for is that you keep that "user agent" secret, even though you have to distribute it to everyone who uses your app. And they have demonstrated that they will happily block that user agent value if you don't do so.

I would be perfectly happy identifying my app to Twitter, and I'm more than happy using OAuth -- it's technically a much better choice than plain passwords. I'm not happy that I have to fulfill an impossible requirement or have my app disabled, and more so that that requirement isn't applied to Twitter themselves or to the other large players they have partnerships with.

No. What Twitter is asking for is that you keep that "user agent" secret, even though you have to distribute it to everyone who uses your app. And they have demonstrated that they will happily block that user agent value if you don't do so.

If they're relying on that "user agent" key for anything important they're asking for trouble.

This really isn't much different from other OAuth providers eg Ebay. Maybe twitter is more explicit in asking that the user agent is kept secret, but many other providers ask the same thing implicitly, and are just as likely to shut off your app if others spam on your user agent.

And yes Twitter is just like thousands of companies that have come before them that pay lip service to partnering companies.

If someone spoofs your user agent and sends a ton of traffic to Twitter, what would you rather they do?

It's like when someone spoofs your credit card - the bank blocks it, and sends you a new one. Inconvenient, yes - but better than the alternative.

If someone spoofed my user-agent and was spamming with it, and they blocked it, I would be annoyed, but I hope I would be understanding that they were doing what they need to maintain their service, and I was unfortunate collateral.

When they pre-emptively ban my user-agent because someone might steal it and spam with it, but don't apply the same rules to themselves and their partners, then I get annoyed.

The important point here is that your app is open-source and you chose to distribute the keys with the source code, rather than require each person who builds it from source to get their own API keys.

I think Twitter's position - that you should not have done this - is completely reasonable.

Out of curiosity, can you not automate the acquisition of the key, so that when somebody runs your app the first time, it goes and obtains the key as required?
I read it as the problem being that Twitter might ban your app if they find that you published your oAuth secrets, which is impossible to avoid.
I think Facebook is worse. For the scale at which the platform operates, the quality of the documentation is abysmal. They're constantly breaking things and making huge shifts in how the platform works, or even just where they're focus is. Very frustrating, especially when you have to explain to a client that you have no idea why feature X just stopped working, despite no one touching any of your code.
+1

Yeah, where else can you develop for an API whose main features go from brand-new to unsupported in less than 12 months? (Not just deprecated, but completely unsupported...) Developing for Facebook essentially soured me to any social API. & Twitter API horror stories have been all too common since way back when the fail whale was still a daily occurrence.

Sorry Facebook, I don't have time to walk your treadmill for a pot of social fool's gold; I have no plans to include Facebook in my apps anymore. And Twitter? There's lots of people already trying to figure out how to monetize the service itself & thus far haven't really come up with anything that seems like it will really work... Not really the kind of foundation I want to build on.

Faced with:

"If I want to distribute an open-source application, Twitter requires that I do not distribute a consumer secret, but rather require every user who downloads my source to register their own app"

and

"Twitter for Android: As mentioned, their keys are in the app’s classes.dex file in plain text. Their keys have been published online, but apparently Twitter doesn’t care."

A developer might consider shipping with a "sample" key pair.

I run an open-source Twitter service (http://preyfetcher.com) and that's exactly what I do. I don't store my consumer key/secret in the public source, same goes for my DB/Twitter Streaming API credentials.

Again, for client apps it sucks because having to register your own API Client is silly for the common user (I would ignore a client that made me do it and I'm a developer). But it's not like it's an issue for _every_ OSS Twitter app.

Preferential treatment. This is the main reason I stopped developing my twitter app. Ugh Twitter, you were doing such a good job with your API, and you let it all go... Sigh.
I thought the difficulty the author stated related to OAuth and desktop apps was the reason Twitter launched XAuth?
Nope; xauth reduces the number of steps a user has to go through for your service to obtain an access token for them (you can prompt them for their username and password rather than launch a web view pointing at Twitter.com). You still need to ship your consumer key with the app, even with Xauth.
Also, all firefox, chrome and safari extensions use javascript and you can read the secret keys in plain text. That include chromed bird, tweetbar and many others. And some of these are not even open source, they just happen to be written in javascript.
Our firefox add-on, Foxy140[1], fetches the consumer key and secret from our server when it starts for the first time. This enables us to change them if they are ever disabled.

[1] http://foxy140.com/

So can still use basic auth, if you use a trick. Good to know for one-off scripts.
I thought this was all just a scam to turn off TweetAdder, or at least force TweetAdder off the API.
Building a startup with a business model that is totally reliant on another startup seems like a bad decision. Might be better to diversify at this point.
Oauth is fine as an option, but when writing server-only analysis and mining tools its creates an unneeded step in the authentication process.
You can obtain one time keys via Twitter's own website for your app, then you just need to sign your requests, which isn't too bad (there are libraries for most languages).
I have not seen a library for bash, however, which is all the previous API needed.
Anyone knows if the Twitter for iPhone/Android get a significantly higher quota of API calls per hour?
Maybe someone will start to make an open-source Twitter alternative.
Already done: http://identi.ca/
Twitter's behavior in the past year has given me pause. However, as to the claim that it's not yet and never will be mainstream: Oprah has not done shows on Facebook [edit: to my knowledge, anyway; don't watch Oprah myself]. Celebrities don't talk to their fanbase on Facebook. We don't go looking for instant news on Facebook (or on Google) -- good recent example for the Bay Area: http://search.twitter.com/search?q=%23sanbrunofire

Twitter is as mainstream as Facebook. Or darn close.

We don't go looking for instant news on Facebook (or on Google)

I don't know if it's related to Google Instant, or preference to Git's servers, or if it's just a part of their strategy to be trending more things real time, but I posted my first public git repo last night.

Shortly after, I was concerned that the name I made up on the spot might have been taken by somebody before me, and (worried that) they might be overly litigious, so I went and googled for the project name, only to find my hours-old project the #4 Google result for the term.

I was shocked and dumb-founded (and very, very tired), but it was 100% awesome to see that technology could even be that much faster than expected.

We live in very fantastical times.

We live in very fantastical times.

We do, indeed. I'm not sure how Github announces additions/changes to Google, but if you notify Google of new/updated content, we're pretty close to that being instantaneous. Of course, as a programmer and nerd I'm always frustrated we're not quite there yet.

I'd like to type in a query into Google, click on sort by newest, and see everything new streaming in.