> 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.
> 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.
> They slowed down making those sorts of radical changes, and to this day you can still browse Twitter with a 3rd-party app like TweetBot and never see cards or ads.
TweetBot is older than the API cap, so did they roll that back? It was 100,000 users (or 2x current users if that was >100,000 which TweetBot probably was). So if they didn't roll it back I guess TweetBot would have stopped adding clients.
> Why does Twitter need to be involved on the client side with consumption of the API?
Twitter is an advertising company. Alternative clients do not show Twitter's ads nor return to Twitter user data, so Twitter makes no money when alternative clients get used but still incurs bandwidth costs. There is no profit, only cost, in providing an exchange for short text messages; the profit all comes in the advertising, and that requires control of the client UI.
> Twitter could make a lot of people happy by re-opening the API access (e.g. third party apps) and adding access control (e.g. teams and channels).
Wouldn't this have a huge impact on their ability to monetize the twitter stream with ads and richer content? Of course this is developer friendly, but does it help them make real money?
"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 could also start charging app devs for API licenses
It already does, which is why Tweetbot, Twitterific and the others had to shift to subscription models.
Ironically, because those third party apps pay for API access for all their global users, and Twitter Blue is only available in about five countries, cutting off third party clients will have an immediate negative impact on Twitter’s revenue.
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.
> 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.
> implementing oauth in an old one-off project that only uses one twitter account to access their api is just a pain in the ass.
There's a way around it. IIRC, you just have to sign up for the developer account using the same credentials as your Twitter account, and it allows you to create a permanent key. It's been months since I did it, but the app I built still works.
> What is the benefit of using twtxt? Ok, it's decentralized, but what actual benefit does that bring?
Right now Twitter is up in arms about proposed changes which make users not have control over their feeds; there will be algorithmic curation so you only see the most popular content from your followers. "Just create a CLI wrapper" only works assuming the APIs are not effected by the changes they are making to the main product, which doesn't really make sense.
> The FAQ on Twitter's dev site says that, "As of March 12, 2012 there is no Advertising API for serving Twitter's promoted products in third party applications." Which means the promoted tweets ought to appear in any timeline that uses the API.
I don't see how the conclusion that tweets ought to appear in any timeline that uses the API follows. That they don't have an API for third-party applications doesn't mean they don't have one for their own applications. In fact, I'd say that it implies the existence of an internal API for serving promoted tweets. The FAQ seems to be accurate, and not at all misleading from where I'm standing. I don't really see how this is an advertising mystery.
That said, the process of investigating the matter was very interesting.
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.
> 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".
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.
reply