Ask HN: Why not build a library that scrapes Twitter's DOM into our own API?
1) Users provide all content to Twitter. Without the users, Twitter is nothing.
2) If users cannot use their favorite clients, then what is Twitter if they're restricting the free-flow of content that generates this so-called "firehose"?
3) Twitter's content is not particularly challenging to analyze. The fact that it is 140 characters of text should make it fairly scrapable.
---------------
Strategies:
a] Depending on what the developer wants, there are multiple approaches. The first would be using cloud instances or even the third-party Twitter clients themselves to distributively spider or scrape Twitter constantly and provide a third-party "stream" or unofficial index.
b] If it's just the user's timeline the client wants to access, this can just be done through any HTTP connection as long as the library is up-to-date enough to properly decode the HTML and DOM elements into the previously readily available JSON elements.
Although the API is a convenience, it almost seems like a non-issue to access content that is publicly available or available when the user logs in if the user is willing to hand over their credentials. I agree it's a nuisance, but for read only access it shouldn't be terribly difficult to accomplish, and for write access it'd be even easier given it's HTTP POST and AJAX calls.
Why not build a replacement "API"?