Interpreting some of Twitter’s API changes | Hacker News Reader

Interpreting some of Twitter’s API changes

marco.org

131 pointsbenatkin56 comments

From Apple to Facebook to Twitter, are we learning that APIs and App Stores are simply traps wherein complements are commoditized so as to drive adoption and to explore (or ripoff) enhancements?

These things seem to be win/win/win for the providers and angst/angst/angst for wannabe collaborators.

I think we are learning, given App.net isn't a closed, centralized system and can't dictate usage terms for users and developers at will.

But those contributors... they gave them $50 bucks. It should be whatever they think it should be!

App.net is not centralized? Pretty sure it is. That said, Dalton has stated he intends to be more open than twitter/FB.

Well then. If Dalton stated it, I'm sure it'll stay that way forever and he'll never change his mind. Let's give him money!

There's a huge difference between founding a company on a vision of being a utility for developers and attempting to fulfill all the promise that Twitter had in the early days, versus the actual Twitter where they never really figured out what they were doing and scaled out to require such levels of investment that the grown ups inevitably moved in and started cannibalizing it for cash.

Yes, let's. Because by giving him money on the basis of a promise, he risks losing money (in the form of future subscriptions) by breaking them. On the other hand, to Twitter your value to them is measured in change per year. I'm willing to bet Twitter doesn't break a lot of promises it makes to its true customers, advertisers.

I was being facetious.

Humor is sometimes lost on the internet.

I see app.net as a project/product by someone spurned by closed systems hoping to build a more open and egalitarian system, but it still is centralized. There is a leap of faith to believe that this goodwill will not alter over time (as business needs change, etc.).

Ideally, I'd love to see something more in line w/ what Dave Winer has proposed -- decentralized services not controlled by a single entity and the like. However, Diaspora was one such attempt in that arena and did not do well.

I'm super excited about App.net and pretty much ditching Twitter in favor of App.net, but I'm quite sure everything you said is false.

Sorry, I was being facetious.

Exactly, developers seem to flock to platforms like Apple, Facebook and Twitter based on the fact that they have a large and growing user base without giving thought to this issue of commoditization of complements and how it ultimately destroy the business or livelihood of these developers.

Most people building products or sharecropping on other people's platform never make meaningful income and yet those platform prefer to announce large sums paid out to developers to encourage you to keep building complements. Apple will claim they paid out $5 billion but when spread out or divided among the numerous app developers it becomes peanut and not enough to pay their bills. You won't hear Apple give you the breakdown as that will expose them and destroy the wrong picture they want to paint to developers. Neither will they tell you that to pay out $5bn they made atleast $2billion based on their 30% cut, off your work and yet countless app developers are not making enough to live on.

They don't tell you that iOS app success is a "lottery": 60% (or more) of developers don't break even

http://arstechnica.com/apple/2012/05/ios-app-success-is-a-lo...

http://andrewchen.co/2012/08/15/mobile-app-startups-are-fail...

I really hope people will think hard before building their business on the back of Apple, Facebook, Twitter or any such platform. You can use them as as distribution without making your business model entirely dependent on them and that is the way to go.

Be your own bitch and not a Twitter, Apple or Facebook bitch:

http://techcrunch.com/2011/05/23/fred-wilson-be-your-own-bit...

Of course that's they way the platform pushers market it, and you're right to be skeptical. But I wouldn't call it a lottery just because very few people win.

It's a marketplace; why would anyone expect the profits to be shared among the vendors? Saying there is a lot of money changing hands is not dishonest.

While I hate to blindly agree and lump all these successful companies into API traps, you are pretty much right. From a business standpoint, if Facebook (or any other API company) sees massive growth/activity in an application on its platform, you better believe they are going to take notice and have some course of action.

You can even throw LinkedIn into this group (http://blog.programmableweb.com/2012/06/21/linkedin-shuts-do...).

The main aggravation/issue stems from developers wanting to use these APIs to gain access to users without fully qualifying the risks. I could easily be building a fantasy sports app on Facebook thinking, "they won't EVER get into this market. They have much bigger problems to solve." 2 years later, they get into the space and shut me down because I am a competitor.

These "wannabe collaborators" are not trying to improve the experience on said platform. They are trying to gain access to a vast database of users with low barriers of entry and an easy to use(/abuse) marketing channels. It's unfortunate that no one has the foresight into understanding where a company as large as Facebook/LinkedIn/etc may pivot into, but only insiders really have first hand knowledge of this sort of thing.

The rules on displaying a tweet on a website seem so batshit insane I can only assume that my interpretation of it is wrong, and it should only apply to applications that provide the functionality of a Twitter client.

Remember that these rules apply to users of the API; I don't think Twitter will come after you for block-quoting a tweet.

Where's the bright and shining line between a website and an application?

If you've got any widget that uses the API the Tweets are going to have to conform, it would seem.

In this case, it would appear that the line is "have you just copy and pasted the text of a tweet or are you getting it from the API?"

They sound unenforceable to me. I'm pretty sure fair use dictates I can quote a person from Twitter without regard to their lame guidelines.

You don't have to follow Twitter's guidelines for displaying a tweet (you're right about fair use, I think); but Twitter doesn't have to authorize your OAuth keys to give you API access either.

You don't need OAuth to pull a (or several) tweet(s).

I would use twitter web or the official apps if they clearly displayed the @username instead of the "real name". The latter is pretty much an useless field that only adds confusion.

I just hope that the new display guidelines don't enforce displaying the real name over the username.

Wow. This all seems very micro-manager-y.

Now I'm curious how Twitter will respond: some open souce developers are working on integrating Twitter posts to buddycloud. That means Tweets will be displayed in a buddycloud channel. How exactly does twitter expect someone running a twitter-buddycloud gateway on their domain. Additionally buddycloud channels (containing tweets) can be displayed in a text client ala https://github.com/Schnouki/bccc#screenshot Are we expected to <blockquote> our VTs? :)

If the hue and cry raises to a high enough level, they might back off a little. "Ask for twice what you want," etc.

If Twitter thinks I won't use <blockquote> to show a tweet when I want to, they're smoking something. That has to mean something else, right?

My interpretation is that it's referring to actually embedding a tweet in a way that pulls it live via the API (or otherwise presented as a tweet entity), and that just quoting someone's tweet (like one would quote an article) is still fine (how could it not be?). I could be wrong.

These kinds of specific restrictions that aren't actually specific enough and really up to their whim are troubling. Twitter needs to be careful that their regulations don't become too much of a burden on their ecosystem. The vagueness and uncertainty of their rules is the problem.

Yeah, on second reading, I was totally wrong. I went and looked at the actual document (what a concept, heh) and they are specifically talking about using applications to display or embed tweets.

I still don't think that's a great idea, but it concerns me a lot less.

That there's any confusion is why this is a problem. Once you start getting into centralized, micromanegerial control of the content of applications, you have to handle all the details, all the edge cases. Law has the same problem.

Question: is there anything stopping an app from using an invisible embedded web view to pull content from Twitter, mimicking a plain browser, and then scraping the content from the DOM as a poor man's API?

It would be tedious as hell, especially now that Twitter is all-Ajax-all-the-time, and it would be a moving target as they made changes, but could Twitter really do anything to stop it?

I was going to ask that exact question.

I think the answer is no, they can't stop you. And perhaps I'm being naïve, but it doesn't seem like it would be too terribly tedious if you used a scraping library, at least not for replacing basic API functions (i.e. getting a user's recent tweets).

Obviously this would be limited to public tweets (no private tweets, no tweeting on the user's behalf, and no DMs).

"Obviously this would be limited to public tweets (no private tweets, no tweeting on the user's behalf, and no DMs)."

I don't think any of those limitations apply. If you can do something via a web browser, you can do it programmatically, depending on how much pain you're willing to endure.

Sorry, right -- I was just thinking of straight-up scraping of public pages. Asking for the user's password and logging in to do more scraping would probably be possible, but a lot more painful.

> Question: is there anything stopping an app from using an invisible embedded web view to pull content from Twitter, mimicking a plain browser, and then scraping the content from the DOM as a poor man's API?

Yes, it's called iframe busting. You can't force a page into an iframe that doesn't want to be there.

Doesn't have to be inside an iframe; it could be an undisplayed UIWebView, or even a headless process such as PhantomJS.

As soon as they get a whiff that people are doing this they'll just block the ip range. Site scrapping is big big business, and a cat and mouse game. Yes, it can be done though, you're right.

They could do this if the scraping were done by a remote server, but if the network activity came from each individual user, they would at best have to resort to looking for behavioral "fingerprints" to what otherwise looks like normal web browsing activity.

Let's just say I wish I had the time for such an endeavor, and I sincerely hope someone out there does.

So, what does this mean for CLI clients?

I hardly ever use them, but things like Bitlbee or the ruby twitter gem are handy once in a while...

I agree. Bitlbee is eons better than Twitter's official client in terms of accessibility for the visual impaired.

This may be seen in the future as the big momement and somehow like a big favour for App.net current hype.

The problem is the teeming masses that are the ones creating all those nonsensical tweets that make Twitter so popular couldn't care less about these problems ...

Apparently the new rules completely obliterate the just-launched branch.com. That's incredibly stupid.

explanation?

They disallow interleaving tweets with custom actions/content, and display styles that deviate from the default.

From my Branch usage, there's no interleaving at all. Am I missing something? Branch posts happen within Branch, not via tweets.

Hmm... I don't know better since I haven't got my invite yet - I was under the impression that conversations were based on posts elsewhere (twitter etc).

What's incredibly stupid is starting a business that depends so heavily on a free third party API that it can be brought down by a rule change.

Nobody is entitled to twitter's data except twitter.

I just had a quick look at Twitter's terms, and it seems pretty clear that tweets are not Twitter's data. The copyright remains with the poster, and Twitter has a non-exclusive licence.

So while I agree with your basic point that starting a business so completely dependent on something that could disappear overnight is probably unwise, it seems it's really only the API that is Twitter's, not the content itself. That could be a significant distinction, depending on how this all plays out.

that seems like a fairly meaningless semantic point. twitter controls the access to the data, therefore it is their data. all the copyright means is that tweet authors are free to take the content of their tweets and put it somewhere else.

twitter controls the access to the data

Twitter controls access to the data via API.

Whether they can do anything about someone scraping their site manually is a different question.

Do you know who the investors in Branch are? :-)

I find myself wondering: why the heck do I even have a twitter account? I hardly ever use it anyway. A political gesture is as good a reason as any to simplify my life.

Turns out I need it for authenticating a couple of external sites. But its days are numbered..

I can't understand how this affects companies like twitmusic.com which just closed a round from 500 startups. Or perhaps disqus.com which has a lot of integrations with twitter in their app.

Can someone shed some light on this?

What does rule 5a, "Tweets that are grouped together into a timeline should not be rendered with non-Twitter content. e.g. comments, updates from other networks," mean for Gwibber and other desktop social clients?

It means they're going to have to remove Twitter.

Twitter doesn't want to be abstracted away as just another stream of messages.

Does this kill Instagram on twitter?

Great timing for app.net.

Reply on news.ycombinator.com