Hi, first of all, let me say that I think this change to the relation between the retweet and the retweeted status makes much sense - it feels much more natural to see it as "user A retweets user B" instead of "user B retweeted by user A", especially if you don't follow B.
A couple of questions inline below: 2009/10/1 Marcel Molina <mar...@twitter.com> > > After experimenting with this approach we've decided that it's a > better bet to craft a payload that will degrade far more gracefully. > So we've redesigned the retweet payload. Rather than having the > original tweet as the top level status with embedded details about who > retweeted it, the retweet is the top level object and within it we > include the original tweet and its author. In your original design, the retweeted message was about to appear in a user's stream, by the original author. I understand that one of the main objectives of this change was to avoid the confusion of people appearing in home timelines that users aren't following. Does that also mean that you'll now show the retweet as sent by the retweeter, not the original poster, and give credit to the original poster in the meta information for a tweet on your web interface? (kind of the opposite of what the first version did) > You'll have full access to > the entire retweeted status and user as well as the original tweet and > its user. So you don't have to make any additional API calls and > should have everything you need to display a retweet distinctively > with attribute to both the original author and the retweeter. Are you considering a retweet as a single entity, or as part of a number of retweets of the original message? In other words, is the "an by 5 others" (if multiple people retweeted a message) still something you want to show somehow? If more than one of my friends retweets a message, should this be displayed as multiple messages now, coming from different people, or are you still collapsing retweets? (the latter doesn't make much sense anymore IMO, as with the inverted relation, the retweet is now coming from the retweeter, not the original poster anymore) > In other > words, these retweeted statuses look a whole lot like regular > statuses. This new design was our instinct to begin with and we > probably should have gone with it. We think it's better and hope you > do too. All the same documented resources will exist. Only the > payloads change. > > The /statuses/retweets/id.format endpoint returned a list of retweet_details before - as I understand it, this data structure no longer exists. What will it return instead? > The following timeline should contain examples of the updated retweet > payload. You can use this to test consuming retweets. > curl http://twitter.com/statuses/user_timeline/testiverse.xml > curl http://twitter.com/statuses/user_timeline/testiverse.json > > In the event that new tweets go into the above timeline that push the > retweets out, you can access a few directly at the following urls: > curl http://twitter.com/statuses/show/4452134416.xml > curl http://twitter.com/statuses/show/4452466408.xml > curl http://twitter.com/statuses/show/4349744308.xml > > The above payloads don't contain a "retweet_count" element yet and > they probably will. Other than that we don't suspect any more major > changes as we approach a full public launch. As always, though, we're > open and solicitous of everyone's feedback. > > If there is no retweet_count, how can apps know if they need to display something like "and by 5 others"? How can they know if it is worth requesting a list of retweets (doesn't make sense if there is just one retweet, as it would waste an API request)? Or (see question above) is showing the list of retweets considered a deprecated feature? > Thanks. > > And finally: when will the retweet API be available for beta testers again? Thanks, Marco > -- > Marcel Molina > Twitter Platform Team > http://twitter.com/noradio >