And yet, we keep using the service. Hrm.
I like http://identi.ca/, an implementation of http://status.net/ .
On the other hand, that's morally draining - particularly when one works on something that's open source.
Sound advice. When a lot of these startups were conceived, that wasn't as obvious as it seems now.
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.)
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.
If they're relying on that "user agent" key for anything important they're asking for trouble.
And yes Twitter is just like thousands of companies that have come before them that pay lip service to partnering companies.
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.
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.
I think Twitter's position - that you should not have done this - is completely reasonable.
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.
"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"
"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.
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.
Twitter is as mainstream as Facebook. Or darn close.
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 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.