I have both practical and philosophical concerns and questions with this proposal. Since I'm a little late in commenting on this, some of these have already been raised. Where I know that is the case, I'll keep it short, but include it to show my support (or not) of the issue.
This post contains practical issues. A companion post will contain philosophical issues. 1. When a retweet is created it is assigned an ID number, just like a status update. Are retweets and status updates numbered from the same sequence of numbers, or separate ones? I mainly ask out of curiosity, but there are some implications as shown below. 2. Is there a limit on the number of times a status update can be retweeted? Again, curiosity, but with implications. 3. In the UI, if a status update is shown that has been retweeted, are all retweeters of the update listed, or, e.g., just ones that I follow? If all retweeters are listed, what if the status update was retweeted, say, 1,000 times? 10,000 times? If just retweeters that I follow are listed, can I somehow see a list of all the retweeters? 4. The response to the status/retweet method provides details about the retweet that was created. Does it also include details on previous retweets of the status update? 5. In the response to the statuses/home_timeline, statuses/ retweeted_by_me, statuses/retweeted_to_me, and statuses/retweets_of_me methods, how are multiple retweets of the same status update encoded? I far as I could see, none of the examples addressed this. Is the status update repeated once per retweet? Or are multiple retweets listed under one instance of the status update that was retweeted? In the latter case, the response would presumably look like: <?xml version="1.0" encoding="UTF-8"?> <statuses> <status> ... <user> ... </user> <retweet_details> ... [details of 1st retweet] </retweet_details> <retweet_details> ... [details of 2nd retweet] </retweet_details> ... </status> </statuses> I could be wrong, but I don't think this is valid XML. I think ya need to have another level of grouping, as in: <?xml version="1.0" encoding="UTF-8"?> <statuses> <status> ... <user> ... </user> <retweets> <retweet_details> ... [details of 1st retweet] </retweet_details> <retweet_details> ... [details of 2nd retweet] </retweet_details> ... </retweets> </status> </statuses> 6. Each XML retweet_details "section" takes around 100-200 characters to encode. If a response that includes retweet_details only returns retweets for those I follow, if I have 20 retweeted status updates each with, say, 20 retweets, that's 20*20*100=40000 plus characters required for the response. Even if the response only includes 1 retweeted status update, but it has been retweeted 10,000 times (Not unheard of! And IMHO it's more likely to happen once this is deployed and folk start writing "retweebots"), that's 1*10000*100=1000000 plus characters. I think there's a problem here that needs to be addressed. 7. If retweets and status updates are numbered from the same sequence of IDs, then presumably statuses/destroy can be used to delete a retweet. If retweets and status updates have separate ID sequences, then I don't see any way to delete a retweet. I think the ability to delete a retweet is essential! BTW, I don't see any delete capability in the proposed UI. 8. If a protected user retweets a status update of a non-protected user, will the protected user always / sometimes / never be listed as a retweeter of the public user's status update? 9. Conversely, if a non-protected user retweets a status update of a protected user, will the protected status update always / sometimes / never be included in the various timelines of the non-protected user? 'Nough for now. I'll probably have more as I think this through more. Comments expected and welcome. Jim Renkel On Aug 13, 3:52 pm, Marcel Molina <mar...@twitter.com> wrote: > Retweetinghas become one of the cultural conventions of the Twitter > experience. It's yet another example of Twitter's users discovering > innovative ways to use the service. We dig it. So soon it's going to > become a natively supported feature on twitter.com. It's looking like > we're only weeks away from being ready to launch it on our end. We > wanted to show the community of platform developers theAPIwe've > cooked up forretweetingso those who want to support it in their > applications would have enough time to have it ready by launch day. We > were planning on exposing a way for developers to create a retweet, > recognize retweets in your timeline and display them distinctively > amongst other tweets. We've also got APIs for several retweet > timelines: retweets you've created, retweets the users you're > following have created, and your tweets that have been retweeted by > others. > > - Creating Retweets > > TheAPIdocumentation for creating retweets can be found here: > > http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweet > > Reminder: Making requests to /statuses/retweet won't work yet as the > feature has not launched. > > - Consuming Retweets in the Timeline > > 1) Retweets in the new home timeline > > We don't want to break existing apps that don't addretweetingsupport > or create a confusing experience for that app's users. So the > /statuses/friends_timelineAPIresource will remain unchanged--i.e. > retweets will *not* appear in it. > > For those who *do* want to support retweets, we are adding a new (more > aptly named) /statuses/home_timeline resource. This *will* include > retweets. The /statuses/friends_timelineAPIresource will continue to > be supported in version 1 of theAPI. In version 2 it will go away and > be fully replaced by /statuses/home_timeline. > > TheAPIdocumentation for the home timeline, which includes retweets, > can be found here: > > http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-home_t... > > Take a look at the example payload in the documentation. The original > tweet that was retweeted Thanks appears in the timeline. Notice the > embedded "retweet_details" element. It contains the user who created > the retweet as well as the date and time the retweet occurred. > > 2) Retweeted by me > timelinehttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee... > > 3) Retweeted to me > timelinehttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee... > > 4) My tweets, > retweetedhttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee... > > Reminder: Making requests to any of these timelines won't work yet as > the feature has not launched. > > UI considerations: > ------------------ > > Here are someearlydraft design mockups of how retweets might appear > on the Twitter website (don't be surprised if > it doesn't look exactly like this). They are presented just as an > example of how retweets can be differentiated visually. > > http://s.twimg.com/retweet-dev-mocks-7-aug-09.png > > Things to note: > > 1) It was important for us that retweets are easily differentiated > visually from regular tweets. If someone you follow retweets a tweet, > the original tweet will appear in your timeline whether you follow the > author of the original tweet or not, just as it currently does when > users use the "RT" convention. Seeing a tweet in your timeline from > someone you don't follow without being told it was shared from someone > you *do* follow could be confusing. So we're encouraging developers to > be mindful of this confusion and make retweets stand out visually from > regular tweets. > > 2) The retweeted tweet shows the username of the first of your > followers to retweet it. If other's subsequently retweet the same > tweet, the retweet should only appear once in a user's timeline > > That's it for now. > > We'll be sending out more updates as we get closer to launching. > > -- > Marcel Molina > Twitter Platform Teamhttp://twitter.com/noradio