"I continue to not understand how Twitter has managed to trick an entire generation of developers into believing they need Twitter's permission to develop a third-party Twitter client. "
It's Twitter's API, and Twitter's servers.
"Has the law changed in some noticeable way to make reverse engineering the official Twitter client and extracting their first party keys for purposes of interoperability suddenly illegal?"
If you don't have permission to use someone else's stuff, you don't use it. We were all taught that in kindergarten.
"We used to do this all the time"
The fact that you abused other's web servers back then doesn't mean that it was right then or now.
> Twitter seem to have an institutional blindness towards the importance of APIs.
Which is especially weird for Twitter. Their official iOS client was a third-party API client they bought. Third-parties created @replies, #hashtags, etc. If anyone should recognize the important of third-parties using APIs, it should be Twitter... yet they've been probably the most abusive of the large APIs.
> Where would Twitter be today if we could continue to use Tweetbot and other clients with our own single-user API-key or so?
So like OAuth? IIRC Twitter used that with all the 3rd party clients. I think the problem is that 3rd party clients filters out ad posts one way or the other. Your other point still stands though, just charge the user API access.
As someone who is apparently "old", I continue to not understand how Twitter has managed to trick an entire generation of developers into believing they need Twitter's permission to develop a third-party Twitter client. Has the law changed in some noticeable way to make reverse engineering the official Twitter client and extracting their first party keys for purposes of interoperability suddenly illegal? We used to do this all the time, at scale before Twitter's invention of the "API key", and the only recourse the service has is to try to detect weird usages of their backend and then punish the users... something that tends to be something of a PR nightmare. (FWIW, I am totally willing to believe the issue is that Apple won't accept them, but then that is Apple being the asshole, and we should be looking into ways of making that market collusion illegal, assuming of course that it isn't already.)
> I wonder if Twitter considered charging users of third party apps to be able to use them? i.e. in order to access Twitter via a third party app, you have to pay a monthly subscription to twitter.
Or even better, third-party developers pay for an API key set on a subscription plan to use the Twitter API in their apps, which makes sense and is a win-win for Twitter and third-party developers.
>With the public API before it was heavily locked down I mainly used it in third party Twitter clients to avoid seeing the (revenue generating) ads in the official Twitter apps - I know many others who did the same. An open, freely usable Twitter API can actively hurt revenues at a time when Twitter desperately needed to demonstrate ability to generate profits.
I wonder if they ever investigated just making API access paid, not free? Users were paying for 3rd party clients making use of the API just because they liked them so much better already, so clearly there was some money in it. And it seems like the Venn diagram of "using client to avoid seeing ads" and "already running, or soon would run, adblock in the browser" would be pretty darn near a circle. Pretty trivial though to make API access require a paid token per account/user, and heavy Twitter users might well put down $1-10/month to use their client of choice.
Don't know, maybe just an artifact of the era. At the time on the web in general it just seems like there was this real aversion to any sort of paid offerings even if they were pure bonuses for heavy users with no actual content hidden at all. That's changed a lot since then, but still particularly for a company desperate for hard revenue and facing controversy over a specific somewhat power-user feature, a bit curious they didn't just try to monetize it. Doesn't seem like an honest presentation of that would even bother that particular subset, certainly not more then having it axed entirely.
>concluding "don't build anything for Twitter" is just throwing a temper tantrum.
Not really. They led people on, over the years, into building on their API. People spent a lot of time and money building Twitter clients. Then they pulled the rug out. Why would you build anything using an API that could get arbitrarily locked down in the future?
Except that they didn't. There wasn't even any discussion, it was just "We're capping OAuth tokens.". Developers offered to pay for access, users offered to pay for the ability to use 3rd party apps.
If they didn't want to go down that path then Twitter could've easily required developers to show monetised tweets/ads.
Nobody I've read is claiming they have a right to access Twitter API. Twitter is legally entitled to do whatever the hell they want. Most of what I've read falls in one of two categories:
1) Criticism of Twitter for implementing a policy that has generated so much ill-will for the company, and essentially prevented 3rd party devs from solidifying Twitter as a kind of a microblogging platform of the Net. Clearly Twitter believes this will serve them better. Most people disagree.
> There was a time around 2010 when building a Twitter API client was the standard demo for a new UI framework — the data model was simple enough that a basic client was the next step up from "Hello world" complexity.
It's fascinating the Twitter we have today and the Twitter from that era are even considered the same app. I wrote a simple Twitter client in Cocoa and Python and even NodeJS. It was such a simple way to get a working, functional, usable demo going that you could immediately show to friends.
Then they realized it's impossible to make money advertising this way and shut it down.
I'm not sure what you mean - what choice do you have? You're either building a twitter bot, or you aren't and it doesn't matter?
Also this isn't much (if any?) of an API change, it's a policy change. And even then it doesn't look like it should negatively affect you unless you were doing something nefarious already.
'Last week Twitter told 3rd party client developers to essentially fuck-off.'
Twitter's subtext being 'we don’t want your clients using our API and diluting our ability to advertise'.
While neither of these statements are true, the concept of offering a protocol instead of an API is an interesting one. Though, the quote "open protocols are basically a gentleman's agreement" does indicate a similar issue to the one that's being projected onto Twitter.
As shantanubala says, upgrading a protocol with mass adoption could be very difficult, this can then cause issues when you want to offer new services, or deprecate certain calls as they may be too complex at scale.
Coordination definitely seems to be a huge issue when dealing with these open social networks. If a security issue is found in a server which can leak information, how long would it take for every server to be patched? I think a good example for this is to ask how many WordPress blogs get hacked because they're running on old copies of the code?
> They've always meant apps that offer more or less the same functionality as official Twitter clients.
No, it started out that way, but then the functionality of the official Twitter clients was expended, and then they redefined it to be so broad as to potentially hit anything that tweeted, and they they went farther still and started going after API keys for things that just consumed the data for their own ends.
> Twitter also gives away their data to anyone that wants it for free. You can be streaming millions of tweets per day within minutes of creating an account.
That's news to me. I maintain the Twitter client library for Go[0], and I still haven't been able to get through the process for getting access to the new streaming API (for testing the library). It requires an application stating your intended purpose and usage. I applied explaining the situation and was rejected (with a request to provide more information - I still have to resubmit that, but it's time and I just haven't gotten around to that yet).
It's possible to stream millions of tweets per day, but good luck trying to do it "within minutes of creating an account". And it's definitely not free.
For full context: I'm already a verified user on Twitter (ie, "blue check mark") and was clear in my application that I was requesting access so I could develop and test the library that other users of the Twitter API develop with. I'm not exactly complaining that they didn't approve the request initially, but if that's not sufficient to get access, it's pretty clear that they're not "giving away their data to anyone that wants it for free".
It's Twitter's API, and Twitter's servers.
"Has the law changed in some noticeable way to make reverse engineering the official Twitter client and extracting their first party keys for purposes of interoperability suddenly illegal?"
If you don't have permission to use someone else's stuff, you don't use it. We were all taught that in kindergarten.
"We used to do this all the time"
The fact that you abused other's web servers back then doesn't mean that it was right then or now.
reply