[twitter-dev] Re: Early developer preview: Retweeting API
I've spent eleven days of reTweet contemplation and these thoughts percolated up: 1. twitter as a phenomena has been driven bottom up by the users 2. forcing new paradigms on our users will result in general unhappiness 3. presenting new paradigms as options to our users will allow happy migration Therefore, May I present to you, VART's : Value Added ReTweets. OK that's a stinky name but I see the value of allowing users to do the instant, no-thought-required new-style RT as well as the old- fashioned edit, trim, comment and send. I think it will take a while for users to grok that the auto retweet method preserves authorship, and a good UI will tag it as such and allow the value of the new api to be perceived. Maybe an additional parameter to statuses/update that this is indeed what's going on? @twittelator / http://stone.com On Aug 13, 2:52 pm, Marcel Molina mar...@twitter.com wrote: Retweeting has 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 the API we've cooked up for retweeting so 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 The API documentation 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 add retweeting support or create a confusing experience for that app's users. So the /statuses/friends_timeline API resource 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_timeline API resource will continue to be supported in version 1 of the API. In version 2 it will go away and be fully replaced by /statuses/home_timeline. The API documentation 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 some early draft 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
[twitter-dev] Re: Early developer preview: Retweeting API
Another question occurred to me as I think about this more and start designing the code that I will use with my site (http://twxlate.com). The statuses/retweeted_by_me method complements the statuses/ user_timeline method: user_timeline Returns the 20 most recent statuses posted from the authenticating user.; retweeted_by_me Returns the 20 most recent retweets posted by the authenticating user.. However, with the user_time method, It's also possible to request another user's timeline via the id parameter.. The retweeted_by_me method does not have this option, and I think it should. Can this be added? I think maybe the statuses/retweets_of_me method should also have an optional id parameter, but I could be wrong about this. The statuses/retweeted_to_me method also does not have an optional id parameter, but the absence here is, I think, correct. Comments expected and welcome. Jim On Aug 18, 7:35 pm, jim.renkel james.ren...@gmail.com wrote: 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 aretweetid 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 specificretweet, 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 theretweetwas created? Specifically, will the retweeting information for B'sretweetshow 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 eachretweetcount 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 RESTAPImethods. (Quoted from theAPIdocumentation under 6) There are pagination limits.), and if it were the latter ya couldn't even return all theretweetinformation 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 aretweet, what do they report? The last update that wasn't aretweet?). 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
[twitter-dev] Re: Early developer preview: Retweeting API
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.renkeljames.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.
[twitter-dev] Re: Early developer preview: Retweeting API
(Cards on the table: I say the following as someone who thinks that retweets are one of the biggest useless annoyances on Twitter.) 1) This change/addition would be great IFF retweets were then NOT part of replies/mentions. I've got a script that checks for mentions and then emails me them, and RTs are just clutter. 2) I would MUCH RATHER see something done about being able to follow a conversation, i.e. I give you a status ID, and you show me all the messages related to it (all the messages in the 'conversation chain' before or after it. This has been a long-standing wish causing many people to try to create their own hackish workarounds because really it has to be supported in the API. 3) It would be nice if someone RTs a message and someone 'favorites' it, the favorite goes to the original author. OTOH then we get into Well is this a 'value added' RT? and then Does 'HAHAHA THIS MADE ME LAFF' count as 'value'? but at least for straight RTs, it would at least bring some value to having this in the API. I realize that not everyone will benefit from every API change, but focusing on something like RTs (which definitely have lots of fans and lots of detractors) instead of conversation threads (which people have been requesting for longer than RTs have even been 'a thing' and which I've never heard anyone be against and can't imagine what an argument against would even look like) is confusing to me. My 2¢ TjL
[twitter-dev] Re: Early developer preview: Retweeting API
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=4 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*1*100=100 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
[twitter-dev] Re: Early developer preview: Retweeting API
This post, containing philosophical issues with the proposed retweet API, is the promised companion to my post containing practical issues. I realize this retweeting API and UI are probably a fait a complis (sp?), modulo addressing practical concerns that I and others have raised, but I'll throw out my two cents worth anyhow. In summary, I don't like this proposal very much. As someone else has pointed out, I think it's akin to driving a tack with a sledge hammer. I see very little wrong / missing with the current retweeting conventions, and I think the twitter community would be better served by addressing these problems / shortcomings that creating something new out of whole cloth. My biggest dislike is that there is no capability to add to the retweet, only exactly duplicate what has already been said. Others have said more eloquently than I could the value of being able to add to a retweet, and I fully support pretty much everything that has been said here. Ya there's a problem with the length of some retweets that have been added to, but the solutions already in place seem to be satisfactory. Was this the real problem that twitter was trying to solve that lead to this API? There is value in knowing that a status update is a retweet, but that could have been much more easily done by adding a new parameter to the status/create method than creating a whole new method, and reporting it's value whenever the status update is reported. AND, it could have been done with 100% backward compatibility, at least as I understand backward compatibility. The implications of requiring changes to existing applications are enormous. Ya there are currently several conventions for indicating a retweet: RT; [unicode recycle symble]; etc. Again, a new parameter to the status/create method solves the problem quite simply and elegantly. AND reduces the problem with the length of retweets. There is value in knowing who has retweeted a tweet, but there is more value in knowing who has responded to a status update in any way. That could have been provided as a status/responses method that I and others have proposed many times, and would result in more value than just being able to find out who has retweeted a status update. I predict, as others have, that retweebots will proliferate and vastly expand and complicate the spam and issues of dealing with it that are already present. Applications and sites that already have a retweet capability will have to change the name of their capability, leading to user confusion, AND implement this new retweeting scheme, leading to even more user confusion. If there were simply a new parameter to the status/create method, I think existing applications and sites would jump all over it, with very little user confusion. When I get there, I know that my site, http://twxlate.com, will definitely implement the existing retweeting conventions (I will have to come up with some other name for it.) and will probably, but not certainly, implement the new API if it is really introduced essentially as it is now. At least I'll be able to do that with less confusion than if I had already implemented the existing retweeting conventions. Again, 'nough for now, but, again, I'll probably come up with more as I think about this more. As always, 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.
[twitter-dev] Re: Early developer preview: Retweeting API
jim.renkel wrote: 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. It is important to be able to un-retweet. I would also like to know how it is done. 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? Protected users' activities should never be disclosed to people outside their list of approved followers. The privacy advantage of the current RT @foo convention is that the reader never knows if @foo actually said what was retweeted unless @foo approved him as a follower. Here's another sticky issue, related to that: What happens when a user posts a tweet, and then a bunch of people retweet it, and then the user deletes the tweet? The original poster doesn't want to be associated with the message anymore and would rather that message not exist. But, the re-tweeters expect to have an archive of everything they retweeted. Regards, Brian
[twitter-dev] Re: Early developer preview: Retweeting API
Thanks for your questions. Responses inline... On Mon, Aug 17, 2009 at 10:31 AM, jim.renkeljames.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=4 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*1*100=100 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
[twitter-dev] Re: Early developer preview: Retweeting API
Brian, Good catch on deleting a retweeted tweet! It was on my list of issues, by I forgot to include it in my post. Hopefully, the twitter folk will respond to this as fast as they added retweet_id so ya can delete retweets! :-) Jim On Aug 17, 1:33 pm, Brian Smith br...@briansmith.org wrote: jim.renkel wrote: 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. It is important to be able to un-retweet. I would also like to know how it is done. 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? Protected users' activities should never be disclosed to people outside their list of approved followers. The privacy advantage of the current RT @foo convention is that the reader never knows if @foo actually said what was retweeted unless @foo approved him as a follower. Here's another sticky issue, related to that: What happens when a user posts a tweet, and then a bunch of people retweet it, and then the user deletes the tweet? The original poster doesn't want to be associated with the message anymore and would rather that message not exist. But, the re-tweeters expect to have an archive of everything they retweeted. Regards, Brian
[twitter-dev] Re: Early developer preview: Retweeting API
On Thu, 13 Aug 2009 23:55:44 +0100 (BST) AlisonW alis...@gmail.com wrote: The idea is great, but the execution (imho) leaves a lot to be desired. There are two types of retweet in my experience: The first is the 'plain' duplication of the original tweet, with just the RT @scnreename on the front, and the proposed API additions serve this very well. But many, indeed I'd argue the majority, of retweets I see are ones where the original message - often a few words and a link - has been commented upon by the retweeter, ie it is *not* a duplication. Sometimes the original is short enough that the commenter can get in with the character limit, sometimes they 'shorten' the original text to get in their comment. There is far greater added value in a retweet when people add their own comment before sending it on its way. Plain re-transmission just fills up the screen. Right. And this mechanism will provide a way to differentiate between plain retweets and value added retweets. +1 to the API team. Chris
[twitter-dev] Re: Early developer preview: Retweeting API
I wonder who would get the eventual credit of a RT. Say I follow userA and userB, both Retweeted a tweet from userC, whom I'm not following. Do I see two tweets from userC from the new home timeline? If so, then with the implied implementation it would be confusing to users as the they are seeing the exact same tweet from the same userC more than once. Image if there are tens of those retweets that can fill up a whole page, will look like spam. If I only see one instance of userC's tweet, then who gets the credit of retweeter? userA or userB? But overall, I like the idea that Retweet is being recognized officially by Twitter and actually being tracked as well. It might be a little bit confusing to users at first, but it shouldn't take them long to adopt. I think it's better to keep it as simple as possible, after all it's just retweet. conversations can be tracked by other means (like @replies), If we mix RT with conversation, then it would be too complicated for regular users to understand and developers to present on UI
[twitter-dev] Re: Early developer preview: Retweeting API
+1 on this. I think the ReTweet concept is more complex than the model in the Retweet API described. While twitter has always been a keep it simple service, I think you will find many users wont use this new functionality if they can't use it the way they do currently (with additional comments).. I think somehow a hybrid of simple rebroadcasting and commenting on the rebroadcast would be powerful enhancement to the Twitter service. Being able to track retweets is very cool, but being able to track what people say about the content they are redistributing is where the power of social communication lies, it drives the conversation forward by engaging more users.. On Aug 13, 2009, at 7:13 PM, stk wrote: I see two UI suggestions: 1) People may find it confusing to see the original author's name in their list, as it's not expected. I think it's better to show the name of the retweeter, rather than the original tweeter (although a link to the original tweet, in the form of the author's name, would be fine and expected). 2) A larger issue with the UI will be the ability to have an option to do one of three things: a) use the original tweeter's text in it's entirety. b) not use the original tweeter's text and instead, use the retweeter's comment - or - c) a mix of (a) and (b) Hope this helps. On Aug 13, 2:31 pm, janole s...@mobileways.de wrote: Will it be possible to comment on the retweeted tweet? If not, people might just continue to use the current RT ... convention. Retweeting can be a way of acknowledging a tweet or disapproving a tweet etc. If you search for RT in search.twitter.com you'll see a lot of commented retweets. Ole -- @janole / mobileways.de / Gravity
[twitter-dev] Re: Early developer preview: Retweeting API
I totally agree with this as it'll allow our clients to just have to look for the one extra field and then we can query the other status ID to find out the originals. This way we have to handle the entire extra node and user node of the XML/json On Aug 13, 11:31 pm, stygz joeisarocks...@gmail.com wrote: @Sean P. Precisely my thoughts. Just a simple retweet_of_status_id field on a status update will allow users to post their own thoughts (a.k.a. keeping the conversation moving) and it would allow client apps to display/link original message however they like. Then readers have all the context they need and if they're interested they can view/ interact with the original tweet as they like. This may seem like a trivial thing to get this excited about, but twitter is all about the conversation and the power of social media is the two-way communication. So why would we want a feature that squelches the conversation and confuses sharing? On Aug 13, 3:10 pm, Sean P. seantpa...@gmail.com wrote: I agree with janole. I believe the simple Reply concept would be best in this regard. For example, if I had a tweet that I found, regardless of who its from, I can retweet it, but link together the original tweet in the same manner that we do for the replies. Thus, we create a chain of where a retweeted message came from but also allows us to make comments. Heck, with this direction, you can blow away the original tweet in your tweet and insert a full 140-character comment and with the chain, Twitter can go back to the last tweet in the chain that isn't linked and we can assume this is the original message and display the original above the user's tweet in the timeline, in a similar fashion of how message boards and forums work. On Aug 13, 2:31 pm, janole s...@mobileways.de wrote: Will it be possible to comment on the retweeted tweet? If not, people might just continue to use the current RT ... convention. Retweeting can be a way of acknowledging a tweet or disapproving a tweet etc. If you search for RT in search.twitter.com you'll see a lot of commented retweets. Ole -- @janole / mobileways.de / Gravity
[twitter-dev] Re: Early developer preview: Retweeting API
Twitter, you will have to create new rules and limits around these new methods. A new breed of spammy app is going to emerge that leverages retweeting. One where users can say, Search for tweets that contain these keywords, and automatically retweet them for me on my account. So, you're going to get Twitter accounts that simply retweet tweets from others to fill their timelines, or to interleave them with the remainder of their tweets that all contain affiliate links. Currently that is not so easy to do, because you have to massage the tweet text, i.e., insert RT and chop some text off if that takes the length beyond 140 characters, not chop off part of an URL if it's at the end of the text, etc. With the new methods all that falls away, because attribution is now given by the retweeted by in the source. No text massaging is required. How about: You can only retweet tweets from those you follow. Just a thought. Dewald
[twitter-dev] Re: Early developer preview: Retweeting API
There are lots of apps that capture this information already. I'm not sure of the name of it but we had one at BarCampNYC that did as you described for anyone who used the hashtag BCNYC5 Regards, Dean Collins Cognation Inc d...@cognation.net +1-212-203-4357 New York +61-2-9016-5642 (Sydney in-dial). +44-20-3129-6001 (London in-dial). -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Friday, August 14, 2009 9:31 AM To: Twitter Development Talk Subject: [twitter-dev] Re: Early developer preview: Retweeting API Twitter, you will have to create new rules and limits around these new methods. A new breed of spammy app is going to emerge that leverages retweeting. One where users can say, Search for tweets that contain these keywords, and automatically retweet them for me on my account. So, you're going to get Twitter accounts that simply retweet tweets from others to fill their timelines, or to interleave them with the remainder of their tweets that all contain affiliate links. Currently that is not so easy to do, because you have to massage the tweet text, i.e., insert RT and chop some text off if that takes the length beyond 140 characters, not chop off part of an URL if it's at the end of the text, etc. With the new methods all that falls away, because attribution is now given by the retweeted by in the source. No text massaging is required. How about: You can only retweet tweets from those you follow. Just a thought. Dewald
[twitter-dev] Re: Early developer preview: Retweeting API
And as for you comment about them being spammy? If you are not following them whats your problem? Eg. Ford might want to set up a twitter account that RT a posts about anyone who mentions Ford in their tweets. Whats your problem with that? Of course it could get publicly commandeered like the 'Skittles' experiment this year but that's not Twitters problem, and it's certainly not 'your' problem. Regards, Dean Collins d...@mytwitterbutler.com +1-212-203-4357 New York +61-2-9016-5642 (Sydney in-dial). +44-20-3129-6001 (London in-dial). -Original Message- From: Dean Collins Sent: Friday, August 14, 2009 9:34 AM To: 'twitter-development-talk@googlegroups.com' Subject: RE: [twitter-dev] Re: Early developer preview: Retweeting API There are lots of apps that capture this information already. I'm not sure of the name of it but we had one at BarCampNYC that did as you described for anyone who used the hashtag BCNYC5 Regards, Dean Collins Cognation Inc d...@cognation.net +1-212-203-4357 New York +61-2-9016-5642 (Sydney in-dial). +44-20-3129-6001 (London in-dial). -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Friday, August 14, 2009 9:31 AM To: Twitter Development Talk Subject: [twitter-dev] Re: Early developer preview: Retweeting API Twitter, you will have to create new rules and limits around these new methods. A new breed of spammy app is going to emerge that leverages retweeting. One where users can say, Search for tweets that contain these keywords, and automatically retweet them for me on my account. So, you're going to get Twitter accounts that simply retweet tweets from others to fill their timelines, or to interleave them with the remainder of their tweets that all contain affiliate links. Currently that is not so easy to do, because you have to massage the tweet text, i.e., insert RT and chop some text off if that takes the length beyond 140 characters, not chop off part of an URL if it's at the end of the text, etc. With the new methods all that falls away, because attribution is now given by the retweeted by in the source. No text massaging is required. How about: You can only retweet tweets from those you follow. Just a thought. Dewald
[twitter-dev] Re: Early developer preview: Retweeting API
Dean, calm down please. I thought of a potential issue. It is Twitter's decision whether they also see it as a potential issue and want to do anything about it. Dewald On Aug 14, 10:37 am, Dean Collins d...@cognation.net wrote: And as for you comment about them being spammy? If you are not following them whats your problem? Eg. Ford might want to set up a twitter account that RT a posts about anyone who mentions Ford in their tweets. Whats your problem with that? Of course it could get publicly commandeered like the 'Skittles' experiment this year but that's not Twitters problem, and it's certainly not 'your' problem. Regards, Dean Collins d...@mytwitterbutler.com +1-212-203-4357 New York +61-2-9016-5642 (Sydney in-dial). +44-20-3129-6001 (London in-dial). -Original Message- From: Dean Collins Sent: Friday, August 14, 2009 9:34 AM To: 'twitter-development-talk@googlegroups.com' Subject: RE: [twitter-dev] Re: Early developer preview: Retweeting API There are lots of apps that capture this information already. I'm not sure of the name of it but we had one at BarCampNYC that did as you described for anyone who used the hashtag BCNYC5 Regards, Dean Collins Cognation Inc d...@cognation.net +1-212-203-4357 New York +61-2-9016-5642 (Sydney in-dial). +44-20-3129-6001 (London in-dial). -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Friday, August 14, 2009 9:31 AM To: Twitter Development Talk Subject: [twitter-dev] Re: Early developer preview: Retweeting API Twitter, you will have to create new rules and limits around these new methods. A new breed of spammy app is going to emerge that leverages retweeting. One where users can say, Search for tweets that contain these keywords, and automatically retweet them for me on my account. So, you're going to get Twitter accounts that simply retweet tweets from others to fill their timelines, or to interleave them with the remainder of their tweets that all contain affiliate links. Currently that is not so easy to do, because you have to massage the tweet text, i.e., insert RT and chop some text off if that takes the length beyond 140 characters, not chop off part of an URL if it's at the end of the text, etc. With the new methods all that falls away, because attribution is now given by the retweeted by in the source. No text massaging is required. How about: You can only retweet tweets from those you follow. Just a thought. Dewald
[twitter-dev] Re: Early developer preview: Retweeting API
For what it's worth, retweeter.com and myretweeter.com are already registered Dewald
[twitter-dev] Re: Early developer preview: Retweeting API
Mark has a point there, Twazzup makes use of RTs from the search results to compute some relevancy/popularity scores. If we consider that those RTs are simple forwards or likes, search result could simply provide each tweets with its number of RTs (total number and/or unique RT'ing user number ?) and one could argue that there is no real need for RT's as entries in the search results. Another nice effect to this : increasing the twitter search memory by reducing the amount of tweets to keep in the index. This is overall a good step, I'd just like to know how disruptive it's going to be for apps that use twitter search API ... @sphilipakis www.twazzup.com On Aug 14, 12:59 pm, Mark Nutter marknut...@gmail.com wrote: So when someone uses this retweet feature, does it actually create a status update in the twitter system? In other words, if I retweet your post, and I use the search api and look for tweets posted by me, will that retweet show up as a search result? Is this new retweet feature going to kill a good portion of the tweets that you might find using the search API? I would have to imagine sites like tweetmeme would be interested to know this. Providing an array of the people who have retweeted a particular link would be a very handy API call to have (without requiring user authentication). Do you plan on including that feature if actual posts aren't being created? On Aug 13, 3:52 pm, Marcel Molina mar...@twitter.com wrote: Retweeting has 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 the API we've cooked up for retweeting so 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 The API documentation 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 add retweeting support or create a confusing experience for that app's users. So the /statuses/friends_timeline API resource 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_timeline API resource will continue to be supported in version 1 of the API. In version 2 it will go away and be fully replaced by /statuses/home_timeline. The API documentation 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 some early draft 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.
[twitter-dev] Re: Early developer preview: Retweeting API
This is super awesome! Can't wait!
[twitter-dev] Re: Early developer preview: Retweeting API
Very useful! Hope it will be soon! It help us avoid search tweet to tracking reweet! 2009/8/13 Beier beier...@gmail.com This is super awesome! Can't wait!
[twitter-dev] Re: Early developer preview: Retweeting API
Will it be possible to comment on the retweeted tweet? If not, people might just continue to use the current RT ... convention. Retweeting can be a way of acknowledging a tweet or disapproving a tweet etc. If you search for RT in search.twitter.com you'll see a lot of commented retweets. Ole -- @janole / mobileways.de / Gravity
[twitter-dev] Re: Early developer preview: Retweeting API
This new api looks very cool. Good work twitter API team. :) Josh
[twitter-dev] Re: Early developer preview: Retweeting API
Will there be a retweeted from client field? I would love to get this data to see which Twitter client/tool aids and promotes spreading of tweets.
[twitter-dev] Re: Early developer preview: Retweeting API
One small suggestion I have for the home_timeline method: Maybe it would be nice to include a parameter flag that allows us to specify if we want retweets included in the response. With this flag set home_timeline would act just like the current friends_timeline. This allows us to give the user an option if they would prefer to have retweets included or not in their home timeline. On Thu, Aug 13, 2009 at 4:43 PM, Josh Roesslein jroessl...@gmail.comwrote: This new api looks very cool. Good work twitter API team. :) Josh -- Josh
[twitter-dev] Re: Early developer preview: Retweeting API
I agree with janole. I believe the simple Reply concept would be best in this regard. For example, if I had a tweet that I found, regardless of who its from, I can retweet it, but link together the original tweet in the same manner that we do for the replies. Thus, we create a chain of where a retweeted message came from but also allows us to make comments. Heck, with this direction, you can blow away the original tweet in your tweet and insert a full 140-character comment and with the chain, Twitter can go back to the last tweet in the chain that isn't linked and we can assume this is the original message and display the original above the user's tweet in the timeline, in a similar fashion of how message boards and forums work. On Aug 13, 2:31 pm, janole s...@mobileways.de wrote: Will it be possible to comment on the retweeted tweet? If not, people might just continue to use the current RT ... convention. Retweeting can be a way of acknowledging a tweet or disapproving a tweet etc. If you search for RT in search.twitter.com you'll see a lot of commented retweets. Ole -- @janole / mobileways.de / Gravity
[twitter-dev] Re: Early developer preview: Retweeting API
@janole wrote: Will it be possible to comment on the retweeted tweet? If not, people might just continue to use the current RT ... convention. Retweeting can be a way of acknowledging a tweet or disapproving a tweet etc. If you search for RT in search.twitter.com you'll see a lot of commented retweets. I expect that if this change is made, many people will retweet and then reply to add their own commentary. But, this raises an issue: If I retweet something and then reply to it, will the reply to the retweet show up for all my followers? Right now the reply would only show up for followers that were also following the original author, but that does not match the intentions of a user that is doing a retweet-then-reply. How are you going to present retweets in the SMS interface? I don't see how the proposed UI answers the question Why am I am seeing this tweet when I'm not following this guy? Is the retweeted by line going to list only people I'm following, or is it going to list ALL people that retweeted the message? From the way it is worded, it looks like it is the latter (all people), but it would be more useful if it was the former. Regards, Brian
[twitter-dev] Re: Early developer preview: Retweeting API
Cool. One request. Could we have an extension to the search API so that I could search for a term which has been tweeted? Scenario: I want to know how many times a particular term has been included in a retweet which I can then aggregate to see how many times it has been retweeted as a total I know it's similar to TweetMeme, but they are links - I want terms :) What do you think? Thanks @Ben_Hall On Thu, Aug 13, 2009 at 10:43 PM, Josh Roessleinjroessl...@gmail.com wrote: This new api looks very cool. Good work twitter API team. :) Josh
[twitter-dev] Re: Early developer preview: Retweeting API
@Sean P. Precisely my thoughts. Just a simple retweet_of_status_id field on a status update will allow users to post their own thoughts (a.k.a. keeping the conversation moving) and it would allow client apps to display/link original message however they like. Then readers have all the context they need and if they're interested they can view/ interact with the original tweet as they like. This may seem like a trivial thing to get this excited about, but twitter is all about the conversation and the power of social media is the two-way communication. So why would we want a feature that squelches the conversation and confuses sharing? On Aug 13, 3:10 pm, Sean P. seantpa...@gmail.com wrote: I agree with janole. I believe the simple Reply concept would be best in this regard. For example, if I had a tweet that I found, regardless of who its from, I can retweet it, but link together the original tweet in the same manner that we do for the replies. Thus, we create a chain of where a retweeted message came from but also allows us to make comments. Heck, with this direction, you can blow away the original tweet in your tweet and insert a full 140-character comment and with the chain, Twitter can go back to the last tweet in the chain that isn't linked and we can assume this is the original message and display the original above the user's tweet in the timeline, in a similar fashion of how message boards and forums work. On Aug 13, 2:31 pm, janole s...@mobileways.de wrote: Will it be possible to comment on the retweeted tweet? If not, people might just continue to use the current RT ... convention. Retweeting can be a way of acknowledging a tweet or disapproving a tweet etc. If you search for RT in search.twitter.com you'll see a lot of commented retweets. Ole -- @janole / mobileways.de / Gravity
[twitter-dev] Re: Early developer preview: Retweeting API
Bravo! Great job Twitter API Team!
