Marcel: thank you for the quick response to my questions. Not surprisingly, your answers have raised a couple of more questions. :-)
1. What happens if I give a retweet id number to the status/show method? An error? The retweeted status message is returned along with information about all of its retweets? I'm really hoping for the second option here, and, if that is not the case currently, I would encourage twitter to make that enhancement. It seems to me to be natural to want information on one specific retweet, just as one can get specific information on one specific status update. For the next 2 questions, assume A is following B and C, that B has retweeted a status update say two days ago, and C has retweeted the same status update yesterday. 2. In the response to a statuses/home_timeline request for user A, will the retweeted status update and all its retweeting information be duplicated at the two appropriate places in the timeline, once for B and once for C? Or will one or the other be elided? 3. If the answer to 2, above, is "the retweeted status update is duplicated", does the retweeting information reflect the state of the twitterverse as it exists at the time the request is made or the state at the time the retweet was created? Specifically, will the retweeting information for B's retweet show that C has also retweeted it, even though C hadn't yet retweeted it when B did? 4. Assume count=20 is specified on the statuses/home_timeline request. Does the retweeted status update and all of its retweets count as just 1 of the 20 status updates in the response (i.e., the response could have more than 20 elements, potentially way more, but all of the retweets of a status update would appear in one "page" of the response)? Or does each retweet count as 1 of the 20 (i.e., the response will have only 20 elements, but the retweets of a single status update could be spread across many, potentially very many, pages)? I think it would have to be the former, as "Clients may [only] request up to 3,200 statuses via the page and count parameters for timeline REST API methods." (Quoted from the API documentation under "6) There are pagination limits".), and if it were the latter ya couldn't even return all the retweet information for a status update that was retweeted more than 3200 times (Which DOES happen.). 5. "statuses/home_timeline" is like "statuses/friends_timeline" but with retweets. There is no method that is like "statuses/ user_timeline" but with retweets. It can be synthesized by merging the results of statuses/user_timeline and statuses/retweeted_by_me method requests, but only for the authenticating user: the statuses/ retweeted_by_me method does not take id and user_id parameters as the statuses/user_timeline method does. I think there's something missing here: if I can see any users status updates, why can't I see their retweets? 6. There are no methods like "statuses/mentions" and "favorites" but including retweets (Or do those methods' results now include retweets?). I see no way at all of synthesizing these. I think these need to be provided for completeness. 7. Similarly, I'm guessing that "statuses/friends" and "statuses/ followers" responses don't include retweets (But if a user's last update was a retweet, what do they report? The last update that wasn't a retweet?). Again, I don't see a way of synthesizing these, and I think methods that do include retweets need to be provided for completeness. The reason for wanting the completeness is to avoid user confusion. Users will get used to seeing retweets, when they exist, when the home timeline is displayed, and assume that if none are displayed, none exist. I fear that they will then make that same assumption when mentions, favorites, friends, and followers are displayed: no retweets displayed, ergo no retweets exist. That may or may not be correct. 'Nough for now. Comments expected and welcome. Answers demanded! "-) Jim Renkel On Aug 17, 1:56 pm, Marcel Molina <mar...@twitter.com> wrote: > 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 aretweetis 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/retweetmethod provides details about > > theretweetthat 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 perretweet? 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 1stretweet] > > </retweet_details> > > <retweet_details> > > ... [details of 2ndretweet] > > </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 1stretweet] > > </retweet_details> > > <retweet_details> > > ... [details of 2ndretweet] > > </retweet_details> > > ... > > </retweets> > > </status> > > </statuses> > > "Is the status update repeated once perretweet?" 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 theretweetand 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 aretweet. I think the ability to > > delete aretweetis essential! BTW, I don't see any delete capability > > in the proposed UI. > > In the absence of an obvious use case for including theretweet'sid, > we were omitting it. Deleting theretweetvia theAPIis 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 aretweet, > >> recognize retweets in your timeline and display them distinctively > >> amongst other tweets. We've also got APIs for severalretweet > >> 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/retweetwon'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 > >> theretweetas well as the date and time theretweetoccurred. > > >> 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 toretweetit. If other's subsequentlyretweetthe same > >> tweet, theretweetshould 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 ... > > read more »
