Thanks for your questions. Responses inline... On Mon, Aug 17, 2009 at 10:31 AM, jim.renkel<james.ren...@gmail.com> wrote: > > 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.
Tweets and retweets are currently numbered from the same sequence of numbers. > 2. Is there a limit on the number of times a status update can be > retweeted? Again, curiosity, but with implications. No. > 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? The UI concern of indicating who has retweeted has been addressed, though it isn't displayed in the sample screenshot. It is collapsed into a count of the total number of retweets with a summary after a certain threshold. > 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? No. > 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> "Is the status update repeated once per retweet?" Yes. > 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. Here you are trading off payload size with number of network calls. Rather than exposing IDs pointing to the author of the retweet and the tweet that is retweeted, we've opted to include the data inline. More pathological scenarios involving retweetbots are mitigated with a combination of measures outside the purview of the platform team. > 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. In the absence of an obvious use case for including the retweet's id, we were omitting it. Deleting the retweet via the API is a very reasonable use case. Thanks. We'll add a 'retweet_id' to the retweet_details section. > 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? Security/visibility concerns are the same as with any status update. > > 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 > -- Marcel Molina Twitter Platform Team http://twitter.com/noradio