My use cases for the Social Graph API:

* Figure out mutual followers vs one-way followers, namely for my
Tweepsect application:

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 <> 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 (, November 
> ( and December ( 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 
> a 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 on With better
> understanding of how you use the graph data, we can improve the quality and
> variety of APIs that we provide.
> Thanks!

Reply via email to