My use cases for the Social Graph API:
* Figure out mutual followers vs one-way followers, namely for my
Tweepsect application: http://tweepsect.com/
This requires a full graph dump, unless you include a parameter in the
statuses/{friends,followers} API calls that indicate whether said
friend is a mutual follower, or a just-friend (stalking) or a just-
follower (stalker). I need to load that data regardless, so if this is
included then I can omit loading the social graph altogether.
* For a Twitter client, for every tweet, figure out if the poster of
said tweet is a mutual follower or not.
Again, if this data was included under each tweet, I wouldn't need to
load the entire social graph.
* Crawling a user's social graph
If I could filter which results to get, such as by geolocation or by
mutualness or by when they last tweeted, it would reduce the amount of
work I have to do.
- shazow
On Jan 8, 12:29 pm, Wilhelm Bierbaum <wilh...@twitter.com> wrote:
> On December 22, 2009 we announced that the social graph method pagination of
> the followers/ids and friends/ids would finally be removed. We announced
> deprecation in September (http://bit.ly/46x1iL), November
> (http://bit.ly/3UQ0LU) and December (http://bit.ly/5VPWk7) of last year. The
> page parameter will be completely removed 1/11/2010. However, the behavior
> of assuming that you want the first cursor page when passing no cursor
> parameter will not.
>
> In the December 2009 announcement, I explained that:
>
> You should always pass a cursor parameter. Starting soon, if you fail to
> pass a cursor, the data returned will be that of the first cursor (-1) and
> the next_cursor and previous_cursor elements will be included.
>
> In response to the feedback we received in
> ahttp://bit.ly/longDiscussionAboutTheSocialGraphwe have decided not to
> immediately remove support for unreliably retrieving a complete friend or
> follower list (by passing neither page nor cursor parameters) on 1/11/2010.
> We understand that too many applications still depend on it. We're working
> on a better way to pull this data; expect another updated announcement on
> this list soon with further details.
>
> We know that the cursor-based social graph APIs can be improved -- we can
> provide richer functionality than we currently expose. To do this, we need
> your help; contribute your use cases for the social graph in response to
> this message onhttp://bit.ly/TwitterDevelopmentTalk. With better
> understanding of how you use the graph data, we can improve the quality and
> variety of APIs that we provide.
>
> Thanks!
