[twitter-dev] Re: Loose ends for List and Retweet APIs
Hi Marcel, I had once suggested this feature: * add retweet_count to every status representation My issue was by placing retweeted statuses once into the home timeline, my app was no longer able to keep track of retweets over time. I think even having the retweet_count still does not change that. Isn't the issue here (at least that's how the home time line works) that a retweet is just placed once into the timeline. So the first time a status is retweeted the retweet count would be 1. After that, and assuming someone is using the user/home timeline the same status would not be placed twice at the top level... so an app polling for new tweets adn potentially tracking retweets would never get an updated retweet count. Only if you pull the info about that retweet directly you would get that count. For many of us, this means wasting a request just for checking the retweet count... we only have 150 per hour. The only way I hopefully can keep track of retweets, count them, etc. is by using the streaming API. I am still waiting for an twitter4j update which hopefully let's me track retweets properly again. If there is a better way to keep track of retweets of a status over time, I'd love to hear it. Cheers Sven On Dec 18, 11:09 am, Marcel Molina mar...@twitter.com wrote: There are some loose ends that need to be tied up in both the List and Retweet APIs to round out the feature set and fix some bugs. I want to crank these all out. So here is a little list I've been building. Please add what I've left out and you think is missing. Retweet: * add retweet_count to every status representation * support paging through the resource that returns all retweets for a given tweet * don't require authentication for *most* read only resources List: * on a user representation, show list count, list memberships count and list subscriptions count * don't require authentication on read only resources * expose a list of ids for a list's members and subscribers (this change will go hand in hand with a new bulk user lookup resource where you provide a list of ids and get back a list of user representations) * count parameter for status timelines of a list appears to do nothing Many other things I'm sure... -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: Loose ends for List and Retweet APIs
OK, if there is room for change then I'd hope for a parameter like: ?include_duplicate_retweets=true This would mean that whenever one of my friends retweets a status, I'd still get a new entry into the home/user time line. It would stop me from having to listen to the streaming methods to get all retweets over time. Even better, the retweet_count would provide a lot more sense to me then. I'd assume the retweet_count reflects all global retweets of a status. This means my app would both be able to track how many of my friends retweeted a status compared to all global retweets (of people I am not or not yet following). It's christmas, me can haz duplicate_retweets=true? Thanx Sven On Dec 18, 3:38 pm, Marcel Molina mar...@twitter.com wrote: Or conceivably (though arguably janky) there could be an additional parameter you provide for the user timeline that opts you in to having retweets appear. e.g. ?include_retweets=true On Fri, Dec 18, 2009 at 3:08 PM, Cameron Kaiser spec...@floodgap.comwrote: It would be good to be able to get retweets in a user's timeline. If that is not possible for backwards compatibility reasons, is it possible to have a function such as retweets_by_user which has similar semantics to retweets_by_me, except we can specify the user whose retweets are being retrieved (requiring appropriate authentication for protected users, of course)? Or, simply a parameter to ask for them optionally? I don't mind this method, but it requires two calls to assemble a user timeline. -- personal: http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com -- The more corrupt the state, the more numerous the laws. -- Tacitus - -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Retweeting via the API does not show up in other's Home Timeline
Hi all, I have switched the retweeting style of my app from using the RT @user text pattern to the new retweet API. If a logged in user on groovytweets.org now hits the green retweet buttons, it will fire off a retweet via the API. Unfortunately, the retweeted messages do not show up in that user's followers Home Timeline (the people following that user should get the retweet). From an API perspective, the request (via Twitter4J) is sent off and returns normally, no error in sight. The API method used is http://twitter.com/statuses/retweet and the statusId of the status who should be retweeted is sent wiht the requuest. Now if I understand the new home timeline correctly, this *might* not be an issue, in the following case: - if another user already had retweeted that status, it might have shown up in the follower's home time line earlier, meaning when I look onto the time line it might not be at the top. Is that understanding correct? I think retweeted statuses who already had been retweeted and 'received' by that user will not show up at the top again. Instead, the UI of twitter.com just adds the new retweeting user to the list of retweeted by for that status. This is of course potentially down in the stream of tweets, so the user might never see it (again). Or there is a bug :-) Either on my side or with twitter. What do you think? Cheers Sven
[twitter-dev] Re: statuses/friends issue?
Thanx, I think the issue exists because I am using the page parameter (via twitter4j). @twitter does deprecating also mean it stops working? :-) Cheers Sven On Dec 8, 1:06 pm, Randy randy.posyn...@gmail.com wrote: Are you using page parameter? If so, it was recently deprecated, so that would explain what you are seeing... the first page over and over again. Check the API documentation to see how to use the cursor parameter. On Dec 6, 8:25 pm, hansamann sven.hai...@googlemail.com wrote: Hi all, my code is calling api method statuses/friends with an increasing paging to get all friends information. Since a couple of hours it seems it never reaches a page with no friends or less than n friends so my code stops the recursion. Anyone similar problems?
[twitter-dev] Re: statuses/friends issue?
I am still seeing this issue. I am pasting some groovy code below, you
can run thus straight in groovyConsole with your own user/pass:
---
import twitter4j.*
import twitter4j.http.*
start()
@Grab(group='net.homeip.yusuke', module='twitter4j',
version='[2.0.10,)')
def start()
{
def users = getUsers() //this never returns!
println (Total: ${user.size()} users.)
}
def getUsers(page = 1)
{
def twitter = new Twitter('user', 'pass')
def users = twitter.getFriendsStatuses(new Paging(page))
println (getUsers: got ${users.size()} users for page $
{page}...)
if (users.size() 90)
return users + getUsers(page+1)
else
return users
}
The output I am getting this this:
oneeverbank-lm:scripts haiges$ groovy twitter_friends_status.groovy
getUsers: got 100 users for page 1...
getUsers: got 100 users for page 2...
getUsers: got 100 users for page 3...
getUsers: got 100 users for page 4...
getUsers: got 100 users for page 5...
getUsers: got 100 users for page 6...
getUsers: got 100 users for page 7...
getUsers: got 100 users for page 8...
getUsers: got 100 users for page 9...
getUsers: got 100 users for page 10...
...
So the recursion is never stopped as there are always 100 users
returned. I just have about 400 friends using this account, so
somethign seems wrong.
Could someone from Twitter please investigate this? It's a big issue
for my app as I am not able to cache the user information any more.
Thanx
Sven
On Dec 6, 8:25 pm, hansamann sven.hai...@googlemail.com wrote:
Hi all,
my code is calling api method statuses/friends with an increasing
paging to get all friends information. Since a couple of hours it
seems it never reaches a page with no friends or less than n friends
so my code stops the recursion.
Anyone similar problems?
[twitter-dev] statuses/friends issue?
Hi all, my code is calling api method statuses/friends with an increasing paging to get all friends information. Since a couple of hours it seems it never reaches a page with no friends or less than n friends so my code stops the recursion. Anyone similar problems?
[twitter-dev] Twitter Retweets in Streaming API?
Hi all, it is my understanding that retweets should show up in the Twitter Streaming API and especially the 'filter' Stream which I am using. My last discussion a few weeks (months) ago with a Twitter Dev confirmed that. I am using the Twitter4J API which has support for the new new Retweet API, still I cannot seem to detect retweets when using the streams. Can someone confirm that retweets (and with that I mean the new retweet payload) makes it into the streams? I'd also like to know what conventions are used for the backwar- compatible text Twitter is using. I saw that statuses which were retweeted result in the RT @username text in the Status itself which is great for backward compatibility. But what happens in case the original message was too long? Is twitter making an exception to the 140 characters in thsi case or just cutting the message? Thanx Sven
[twitter-dev] Re: Retweet streams have been frozen for 2 weeks
Could it be there are some issues with the streaming API and the retweets there, too? I cannot see retweeted messages in the new xml format there... just the normal Status payload. Sven On Nov 29, 6:34 am, John Kalucki jkalu...@gmail.com wrote: I forwarded this thread to the engineers who developed theReTweet feature. On Nov 29, 12:34 am, Rich rhyl...@gmail.com wrote: Yep mine too, the ReTweeted by others stream on my account hasn't been updated since 17th November. The others are OK though On Nov 29, 6:53 am, Zac Bowling zbowl...@gmail.com wrote: Theretweetstreams have been frozen for 2 weeks. See here:http://twitpic.com/rfcjv I thought it was just me, but a coworker is seeing this as well. Don't need this for dev but it would be nice to know what is going on. The pages take a long time to load and then show that above. I wonder if something is failing and just returning some kind of cache maybe? Don't know. A quick search on twitter shows I'm not alone:http://twitter.com/#search?q=retweets%20by%20others Zac Bowling
[twitter-dev] Re: Retweet API launched to 100% of users
I am working with Twitter4J which should have support for the latest retweet format in the current Snapshot. Somehow I cannot get the retweetedStatus object, it returns null, so I am wondering if retweets are also part of the streaming API which I am using. I am using the filter stream and would like to detect retweeted messages in this stream. Based on the last information form Twitter this should be possible and the retweetedStatus info should be part of the filter stream statuses. Is this still correct? Cheers Sven On Nov 19, 5:16 pm, Marcel Molina mar...@twitter.com wrote: Back in August we announced plans to release the Retweet feature along with an API to publish and consume retweets. Over the last few months we've been gradually opening up the feature to more users as we performance test and refine it. You can see some of the original announcement emails around retweets here:http://groups.google.com/group/twitter-api-announce/browse_thread/thr...http://groups.google.com/group/twitter-api-announce/browse_thread/thr...http://groups.google.com/group/twitter-api-announce/browse_thread/thr...http://groups.google.com/group/twitter-api-announce/browse_thread/thr... Today we've launched the feature to 100% of users. You can now consume retweets via the /statuses/home_timeline resource, as well as all the specialized retweet timelines. For backwards compatibility reasons we're stripping retweets out of the friends_timeline resource as well as the user_timeline resource. If you plan on implementing support for consuming retweets from timelines, switch all instances of /statuses/friends_timeline to /statuses/home_timeline. All the relevant retweet documentation can be found here:http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweethttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-home_t...http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweets To those implementing this feature in your clients, I'd suggest taking some UI cues from what we've done on Twitter.com:http://s3.amazonaws.com/twitter_production/differentiating-retweets.png Notice how the retweet by @ablegrape of @wblakegray's tweet is clearly differentiated from the surrounding tweets with a distinctive retweet icon and the Retweeted by label along the bottom. This is just one way of doing it. Use whatever interface you think makes sense. What's important is communicating to your users that the tweet they are seeing was shared with them by someone they follow so they don't get confused by seeing tweets in their timeline from people they aren't following. We're just getting started with the retweet feature but we're happy with this initial v1 we pushed out. We're really looking forward to seeing how everyone works with this new API. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] New NEW retweet API and retweet text
Hi all, looking at this http://twitter.com/statuses/user_timeline/testiverse.xml It seems like retweeted status mesage now may contain more/different text, right, the retweet (now at the top) is: RT @luciuskwok: Ideas are cheap. Implementation is hard. #360iDev And the original is this: Ideas are cheap. Implementation is hard. #360iDev --- Sorry, but I am now really getting confused. Is this just a bad example and the text would normally be the same or does the statuses/ retweet method now let you change the text you want to retweet. If so, still 140 character limit? What is the proposed way to handle over-size messages. Cheers Sven
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
John, thanx for your comment over at groovyconsole.appspot.com - http://groovyconsole.appspot.com/view.groovy?id=19003 In case you do not get updates on comments there, let me ask my main question again. This would make my (our) lives a lot easier when it comes to retweet tracking, still it would not require me to use the streaming API: If we could pass multiple status ids into the statuses/retweets method in which case it returns summaries for each tweets retweets like the count, only the screennames that retweeted, etc. I could keep it on one system. It would help me a lot. Are you investigating support for this? Is this under consideration? Thx Sven On Sep 24, 9:50 am, John Kalucki jkalu...@gmail.com wrote: I'll update the Wiki to reflect the new reality. Retweetswill begin to flow through all /1/statuses/* resources soon -- in advance of the full retweet launch. This will give developers time to test and deploy features in advance. Also, the retweet volume is very low now, so exceptions should be easier to handle. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Sep 23, 10:15 pm, hansamann sven.hai...@googlemail.com wrote: John, I assume the method to use would then be http://stream.twitter.com/1/statuses/filter.format It does not mention that it includesretweets, but it will once the API is live? Cheers Sven On Sep 23, 9:38 pm, hansamann sven.hai...@googlemail.com wrote: Thanx, I'll give that a try. On Sep 23, 8:11 pm, John Kalucki jkalu...@gmail.com wrote: Retweetswill be searched by the follow parameter on the filter resource. The intention is that you get all statuses (including retweets) where any user_id field matches your predicate list. So, tweets, replies and both ends ofretweets. If GAE cuts you off after 30 seconds, then you shouldn't open connections to the Streaming API. Gather ye data elsewhere and smuggle it into GAE by other means. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Sep 23, 7:50 pm, hansamann sven.hai...@googlemail.com wrote: One reason for example is being on Google App Engine and having a 30 second limit. I cannot keep the connection open. Another reason is I am not interested in everyonesretweets, just the retweets(and in this case all, not just a sample) of that twitter user's friends. What do you think? Cheers Sven On Sep 22, 9:49 pm, John Kalucki jkalu...@gmail.com wrote: Retweetaggregators should use the Streaming API /1/statuses/sample method to gather a sample ofRetweetsor apply for the fullRetweet stream on /1/statuses/retweet. The Streaming API may be in Alpha, but the service has been very reliable. I'm unaware of any technical issues that would block a reasonably proficient service developer on a reasonable stack from integrating Streaming API results in fairly short order. I'm sure there are examples of byzantine stacks upon which this isn't true, but workarounds can be found. -John Kaluckihttp://twitter.com/jkalucki Services, TwitterInc. On Sep 22, 9:27 pm, hansamann sven.hai...@googlemail.com wrote: I am still hoping for an answer to the questions in this thread, but meanwhile here is another idea the Twitter Team might find interesting. As it seems many of us want to trackretweets. What we are really interested in is the number ofretweetsover time so we can find trending topics, in my case within a community (e.g. not for public timeline tweets, just for the tweets among my friends). So: why not have a method that is capable of returning severalretweetcounts? So what if statuses/retweetswould either accept *just a single id* in which case the behaviour is as currently described, or *many ids* in which case the response is a summary for many statusIds. The summary should contain the usernames that retweeted the original ids and the retweetcounts at least. If the API is left as it is, guess a lot of us will need to get whitelisted. Excessively calling status/retweetsfor single tweets cannot be the intention of Twitter. Also manyretweetaggregators will really be in trouble (unless they use the streaming apis, but those again are alpha and some cannot use them for technical reasons) as the twitter accounts of their users are not whitelisted and as such constraint to 150 API calls. Come on, would anyone at least consider that or let us know best practices for trackingretweetsafter the api is launched? Cheers Sven On Sep 18, 4:37 pm, hansamann sven.hai...@googlemail.com wrote: Excactly, my main point, too. The problem is I want
[twitter-dev] Requesting shadow role for streaming API
Hi all, what is the process for requesting the shadow role (up to 50 000 follower ids) for the streaming APIs? Is there a special form someone can link me to? I'd need the shadow role for the 'groovytweets' user account, we just passed the magic 400 followers and I want to use the streaming api. Thx Sven
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
One reason for example is being on Google App Engine and having a 30 second limit. I cannot keep the connection open. Another reason is I am not interested in everyones retweets, just the retweets (and in this case all, not just a sample) of that twitter user's friends. What do you think? Cheers Sven On Sep 22, 9:49 pm, John Kalucki jkalu...@gmail.com wrote: Retweetaggregators should use the Streaming API /1/statuses/sample method to gather a sample of Retweets or apply for the fullRetweet stream on /1/statuses/retweet. The Streaming API may be in Alpha, but the service has been very reliable. I'm unaware of any technical issues that would block a reasonably proficient service developer on a reasonable stack from integrating Streaming API results in fairly short order. I'm sure there are examples of byzantine stacks upon which this isn't true, but workarounds can be found. -John Kaluckihttp://twitter.com/jkalucki Services, TwitterInc. On Sep 22, 9:27 pm, hansamann sven.hai...@googlemail.com wrote: I am still hoping for an answer to the questions in this thread, but meanwhile here is another idea the Twitter Team might find interesting. As it seems many of us want to track retweets. What we are really interested in is the number of retweets over time so we can find trending topics, in my case within a community (e.g. not for public timeline tweets, just for the tweets among my friends). So: why not have a method that is capable of returning severalretweetcounts? So what if statuses/retweets would either accept *just a single id* in which case the behaviour is as currently described, or *many ids* in which case the response is a summary for many statusIds. The summary should contain the usernames that retweeted the original ids and the retweetcounts at least. If the API is left as it is, guess a lot of us will need to get whitelisted. Excessively calling status/retweets for single tweets cannot be the intention of Twitter. Also manyretweetaggregators will really be in trouble (unless they use the streaming apis, but those again are alpha and some cannot use them for technical reasons) as the twitter accounts of their users are not whitelisted and as such constraint to 150 API calls. Come on, would anyone at least consider that or let us know best practices for tracking retweets after the api is launched? Cheers Sven On Sep 18, 4:37 pm, hansamann sven.hai...@googlemail.com wrote: Excactly, my main point, too. The problem is I want to track how tweets 'develop' over time. This means I would need to pull the status/retweets every minute or so for every tweet I am tracking. There is a 150 api call limit currently... without whitelisting I will be doomed. I was hoping that the 'retweeted to me' timeline would include a 'count' field for eachretweet. I could then have checked that timeline every minute (and pull the info for the last 50 retweets to me let's say). This would just have consumed 1 request each minute for example... not 1 request per tweet tracked per minute, which... could be a lot. Any ideas? Otherwise: how can I get the app groovytweets whitelisted? Thanx Sven On Sep 18, 3:21 pm, Nick Arnett nick.arn...@gmail.com wrote: On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina mar...@twitter.com wrote: Asking developers to collapse retweets in timelines is onerous, complicated and confusing. We're not going to do it that way. We are going to add a resource that gives you all retweets for a given tweet. In timelines you will get only the firstretweet. You can then request all retweets for that tweet at any time to get up to 100 retweets that have been created for it. Will timelines show if additional retweets exist for each tweet? Otherwise, won't we have to make the request for every tweet to find out if there are others? Nick
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
Is there a way to connect to the streaming api and only get my friends retweets? Or would I get *everyones* retweets and have to filter millions of unwanted messages out? On Sep 22, 9:49 pm, John Kalucki jkalu...@gmail.com wrote: Retweetaggregators should use the Streaming API /1/statuses/sample method to gather a sample of Retweets or apply for the fullRetweet stream on /1/statuses/retweet. The Streaming API may be in Alpha, but the service has been very reliable. I'm unaware of any technical issues that would block a reasonably proficient service developer on a reasonable stack from integrating Streaming API results in fairly short order. I'm sure there are examples of byzantine stacks upon which this isn't true, but workarounds can be found. -John Kaluckihttp://twitter.com/jkalucki Services, TwitterInc. On Sep 22, 9:27 pm, hansamann sven.hai...@googlemail.com wrote: I am still hoping for an answer to the questions in this thread, but meanwhile here is another idea the Twitter Team might find interesting. As it seems many of us want to track retweets. What we are really interested in is the number of retweets over time so we can find trending topics, in my case within a community (e.g. not for public timeline tweets, just for the tweets among my friends). So: why not have a method that is capable of returning severalretweetcounts? So what if statuses/retweets would either accept *just a single id* in which case the behaviour is as currently described, or *many ids* in which case the response is a summary for many statusIds. The summary should contain the usernames that retweeted the original ids and the retweetcounts at least. If the API is left as it is, guess a lot of us will need to get whitelisted. Excessively calling status/retweets for single tweets cannot be the intention of Twitter. Also manyretweetaggregators will really be in trouble (unless they use the streaming apis, but those again are alpha and some cannot use them for technical reasons) as the twitter accounts of their users are not whitelisted and as such constraint to 150 API calls. Come on, would anyone at least consider that or let us know best practices for tracking retweets after the api is launched? Cheers Sven On Sep 18, 4:37 pm, hansamann sven.hai...@googlemail.com wrote: Excactly, my main point, too. The problem is I want to track how tweets 'develop' over time. This means I would need to pull the status/retweets every minute or so for every tweet I am tracking. There is a 150 api call limit currently... without whitelisting I will be doomed. I was hoping that the 'retweeted to me' timeline would include a 'count' field for eachretweet. I could then have checked that timeline every minute (and pull the info for the last 50 retweets to me let's say). This would just have consumed 1 request each minute for example... not 1 request per tweet tracked per minute, which... could be a lot. Any ideas? Otherwise: how can I get the app groovytweets whitelisted? Thanx Sven On Sep 18, 3:21 pm, Nick Arnett nick.arn...@gmail.com wrote: On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina mar...@twitter.com wrote: Asking developers to collapse retweets in timelines is onerous, complicated and confusing. We're not going to do it that way. We are going to add a resource that gives you all retweets for a given tweet. In timelines you will get only the firstretweet. You can then request all retweets for that tweet at any time to get up to 100 retweets that have been created for it. Will timelines show if additional retweets exist for each tweet? Otherwise, won't we have to make the request for every tweet to find out if there are others? Nick
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
Thanx, I'll give that a try. On Sep 23, 8:11 pm, John Kalucki jkalu...@gmail.com wrote: Retweets will be searched by the follow parameter on the filter resource. The intention is that you get all statuses (including retweets) where any user_id field matches your predicate list. So, tweets, replies and both ends of retweets. If GAE cuts you off after 30 seconds, then you shouldn't open connections to the Streaming API. Gather ye data elsewhere and smuggle it into GAE by other means. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Sep 23, 7:50 pm, hansamann sven.hai...@googlemail.com wrote: One reason for example is being on Google App Engine and having a 30 second limit. I cannot keep the connection open. Another reason is I am not interested in everyones retweets, just the retweets (and in this case all, not just a sample) of that twitter user's friends. What do you think? Cheers Sven On Sep 22, 9:49 pm, John Kalucki jkalu...@gmail.com wrote: Retweetaggregators should use the Streaming API /1/statuses/sample method to gather a sample of Retweets or apply for the fullRetweet stream on /1/statuses/retweet. The Streaming API may be in Alpha, but the service has been very reliable. I'm unaware of any technical issues that would block a reasonably proficient service developer on a reasonable stack from integrating Streaming API results in fairly short order. I'm sure there are examples of byzantine stacks upon which this isn't true, but workarounds can be found. -John Kaluckihttp://twitter.com/jkalucki Services, TwitterInc. On Sep 22, 9:27 pm, hansamann sven.hai...@googlemail.com wrote: I am still hoping for an answer to the questions in this thread, but meanwhile here is another idea the Twitter Team might find interesting. As it seems many of us want to track retweets. What we are really interested in is the number of retweets over time so we can find trending topics, in my case within a community (e.g. not for public timeline tweets, just for the tweets among my friends). So: why not have a method that is capable of returning severalretweetcounts? So what if statuses/retweets would either accept *just a single id* in which case the behaviour is as currently described, or *many ids* in which case the response is a summary for many statusIds. The summary should contain the usernames that retweeted the original ids and the retweetcounts at least. If the API is left as it is, guess a lot of us will need to get whitelisted. Excessively calling status/retweets for single tweets cannot be the intention of Twitter. Also manyretweetaggregators will really be in trouble (unless they use the streaming apis, but those again are alpha and some cannot use them for technical reasons) as the twitter accounts of their users are not whitelisted and as such constraint to 150 API calls. Come on, would anyone at least consider that or let us know best practices for tracking retweets after the api is launched? Cheers Sven On Sep 18, 4:37 pm, hansamann sven.hai...@googlemail.com wrote: Excactly, my main point, too. The problem is I want to track how tweets 'develop' over time. This means I would need to pull the status/retweets every minute or so for every tweet I am tracking. There is a 150 api call limit currently... without whitelisting I will be doomed. I was hoping that the 'retweeted to me' timeline would include a 'count' field for eachretweet. I could then have checked that timeline every minute (and pull the info for the last 50 retweets to me let's say). This would just have consumed 1 request each minute for example... not 1 request per tweet tracked per minute, which... could be a lot. Any ideas? Otherwise: how can I get the app groovytweets whitelisted? Thanx Sven On Sep 18, 3:21 pm, Nick Arnett nick.arn...@gmail.com wrote: On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina mar...@twitter.com wrote: Asking developers to collapse retweets in timelines is onerous, complicated and confusing. We're not going to do it that way. We are going to add a resource that gives you all retweets for a given tweet. In timelines you will get only the firstretweet. You can then request all retweets for that tweet at any time to get up to 100 retweets that have been created for it. Will timelines show if additional retweets exist for each tweet? Otherwise, won't we have to make the request for every tweet to find out if there are others? Nick
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
I am still hoping for an answer to the questions in this thread, but meanwhile here is another idea the Twitter Team might find interesting. As it seems many of us want to track retweets. What we are really interested in is the number of retweets over time so we can find trending topics, in my case within a community (e.g. not for public timeline tweets, just for the tweets among my friends). So: why not have a method that is capable of returning several retweet counts? So what if statuses/retweets would either accept *just a single id* in which case the behaviour is as currently described, or *many ids* in which case the response is a summary for many statusIds. The summary should contain the usernames that retweeted the original ids and the retweet counts at least. If the API is left as it is, guess a lot of us will need to get whitelisted. Excessively calling status/retweets for single tweets cannot be the intention of Twitter. Also many retweet aggregators will really be in trouble (unless they use the streaming apis, but those again are alpha and some cannot use them for technical reasons) as the twitter accounts of their users are not whitelisted and as such constraint to 150 API calls. Come on, would anyone at least consider that or let us know best practices for tracking retweets after the api is launched? Cheers Sven On Sep 18, 4:37 pm, hansamann sven.hai...@googlemail.com wrote: Excactly, my main point, too. The problem is I want to track how tweets 'develop' over time. This means I would need to pull the status/retweets every minute or so for every tweet I am tracking. There is a 150 api call limit currently... without whitelisting I will be doomed. I was hoping that the 'retweeted to me' timeline would include a 'count' field for eachretweet. I could then have checked that timeline every minute (and pull the info for the last 50 retweets to me let's say). This would just have consumed 1 request each minute for example... not 1 request per tweet tracked per minute, which... could be a lot. Any ideas? Otherwise: how can I get the app groovytweets whitelisted? Thanx Sven On Sep 18, 3:21 pm, Nick Arnett nick.arn...@gmail.com wrote: On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina mar...@twitter.com wrote: Asking developers to collapse retweets in timelines is onerous, complicated and confusing. We're not going to do it that way. We are going to add a resource that gives you all retweets for a given tweet. In timelines you will get only the firstretweet. You can then request all retweets for that tweet at any time to get up to 100 retweets that have been created for it. Will timelines show if additional retweets exist for each tweet? Otherwise, won't we have to make the request for every tweet to find out if there are others? Nick
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
Excactly, my main point, too. The problem is I want to track how tweets 'develop' over time. This means I would need to pull the status/retweets every minute or so for every tweet I am tracking. There is a 150 api call limit currently... without whitelisting I will be doomed. I was hoping that the 'retweeted to me' timeline would include a 'count' field for each retweet. I could then have checked that timeline every minute (and pull the info for the last 50 retweets to me let's say). This would just have consumed 1 request each minute for example... not 1 request per tweet tracked per minute, which... could be a lot. Any ideas? Otherwise: how can I get the app groovytweets whitelisted? Thanx Sven On Sep 18, 3:21 pm, Nick Arnett nick.arn...@gmail.com wrote: On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina mar...@twitter.com wrote: Asking developers to collapse retweets in timelines is onerous, complicated and confusing. We're not going to do it that way. We are going to add a resource that gives you all retweets for a given tweet. In timelines you will get only the first retweet. You can then request all retweets for that tweet at any time to get up to 100 retweets that have been created for it. Will timelines show if additional retweets exist for each tweet? Otherwise, won't we have to make the request for every tweet to find out if there are others? Nick
[twitter-dev] Re: since_retweet_id needed?
anyone? On Sep 2, 3:40 pm, hansamann sven.hai...@googlemail.com wrote: To track retweets over time and to not waste resources, I believe it would be great to get a since_retweet_id parameter for the new retweet status methods like statuses retweeted_to_me If we just have a status_id, you cannot pull for new retweets over time I believe. If you use the statusId, once you pulled a status with that Id, you should theoretically no longer get any more retweets for that status. Now having a since_retweet_id makes a lot of sense in this case. You can poll for new retweets without having to pull in the last 50 or so all the time, which saves resources. What do you think? Cheers Sven
[twitter-dev] Retweet API and multiple retweets in timeline
Hi all, this questions might have been asked already, but a quick search in this mailing list did not lead me to a clear response... so I apologize if this topic was discussed in detail already. My question: - if a tweet is retweeted several timese, e.g. tweet X is retweeted by my friend A and my friend B, it is likely these retweets are not taking place the same time. - my assumption and question is if the 2 retweets in this case show up as two tweets in the home timeline. What troubles me is how I can detect that a tweet was retweeted. I intend to save the last pulled statusId and then just pull tweets from the home_timeline from the last statusId. I hope to get the 'new retweets' as they happen as new people are retweeting. If the api will aggregate the retweets under the stausId of the original message, I will not be updated of new retweets in this case. On the other side, if a new retweet will add the original status a second time (possibly with the new total retweets, e.g. several retweet_details) then I track the retweet count. What do you think? Cheers Sven
[twitter-dev] Re: New ReTweet API
I'd also like to know this. The examples on the twitter API page all just show one retweet_details section, this would mean that if multiple of your friends to retwee the same status, it will be added multiple times to the home timeline. this way, there is also no problem wiht tracking retweets of the same status over time, as you get new statuses into the timeline. Cheers Sven On Aug 14, 11:35 am, Houshang Nayeb shang...@gmail.com wrote: I have the following question: If one of my tweets is retweeted multiple times, what will be the return value of “retweets_of_me.format” ? Will it be one record with multiple “retweet_details” sections? If yes, will there be a “count” for the number of times it has been retweeted? If no, then what happens? Thanks!
[twitter-dev] since_retweet_id needed?
To track retweets over time and to not waste resources, I believe it would be great to get a since_retweet_id parameter for the new retweet status methods like statuses retweeted_to_me If we just have a status_id, you cannot pull for new retweets over time I believe. If you use the statusId, once you pulled a status with that Id, you should theoretically no longer get any more retweets for that status. Now having a since_retweet_id makes a lot of sense in this case. You can poll for new retweets without having to pull in the last 50 or so all the time, which saves resources. What do you think? Cheers Sven
[twitter-dev] Re: Twitter Update, 8/10 noon PST
Can someone post a link to some online resources explaining more about geometric back-offs? Did a search, did not find a whole lot. Thx Sven On Aug 10, 7:18 pm, jim.renkel james.ren...@gmail.com wrote: Yup, when you do back-offs, ya can't do them deterministically, ya gotta do them for a random amount, generally uniformly distributed between some upper and lower bounds. It's the bounds that increase geometrically or exponentially, up to some limit, but the each back-off should be random between the bounds. If the back-offs are not randomized, its leads to synchronicity, as you noted. BTW, all standardized back-offs of which I am aware specify randomized back-off. Jim Renkel On Aug 10, 7:54 pm, Michael Chang thenewm...@gmail.com wrote: On Mon, Aug 10, 2009 at 3:36 PM, Dewald Pretorius dpr...@gmail.com wrote: On Aug 10, 3:57 pm, Ryan Sarver rsar...@twitter.com wrote: As such the system has more general strain on it and thus will produce some more 502/503 errors. If you see them, you should do a geometric back off instead of just sending a new request. Ryan, What starting value and what common ratio of a geometric back off would you recommend? One issue with back off (geometric or otherwise) is that if everyone uses the same values; it won't work. Think about it -- let's say 10 000 users all access the system simultaneously and all of them get 502/503 errors. Then let's say they all wait five seconds before retrying. Once those five seconds are up; they will all simultaneously accesss the site again, and likely again get the same 502/503 errors. This causes them all to back off again, say, for 25 seconds. Then they will all again contact the server again, at the same time, and so on and so forth until either they all give up, or until the end of time, whichever comes first. (Yes, this is a simplified example, but it should get the point across. In practice, at least a few users might get through every time, and eventually, yes, everyone would get served if they are patient enough. But if everyone uses different back-off values, then the traffic becomes somewhat more even, and thus the servers can cope with the load more easily.) -- Thanks, Michael Chang I may not be able to open heavily-formatted Word, Powerpoint, or Excel documents. Send at your own risk.
[twitter-dev] Re: DDoS Status Update
I saw some examples for those redirects and they seem to send even an invalid Location header: Location: /?somekey It's illegal for the Location header to contain a relative URL: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 This causes APIs like twitter4j on Google App Engine to fail. Making this a absolute URL would work... or would that somehow break the security measuers taken? Maybe the Twitter dev team can consider to make the Location URLs absolute, a lot of us would then at least be able to do some stuff with Twitter while these attacks take place. Cheers Sven On Aug 7, 12:44 pm, Chad Etzel c...@twitter.com wrote: Inline about 302's. I'm trying to get info on your other questions: On Fri, Aug 7, 2009 at 3:27 PM, Justin Hartonyxra...@gmail.com wrote: Does this affect POST as well as GET? The issue here is the way clients handle 30x after POST. Most clients (now by convention) do not respect the RFC (http://www.w3.org/Protocols/rfc2616/rfc2616- sec10.html#sec10.3) and will send a GET after POST always. Some clients will respect the method, but not re-post any data. We need to be sure we are all expecting the right things. You are correct that lots of clients now redirect with a GET instead of a POST, even curl does this, which is a bummer. The best thing to do in that case is to catch the response code (without following the redirect automatically) and manually re-attempt the POST with the new location. We know it's a pain, but that's one way around the POST-GET problem. -Chad
[twitter-dev] Re: oauth redirects fail....
I experience the same, hope this is just the Twitter DOS attack aftermath. My app cannot request a requestToken for example, which results in a time out on my pages as this is the first thing you do before you redirect to twitter. Also, I cannot seem to get the friends timeline, friends and followers at least not regularly I believe. Anyone else? Cheers Sven On Aug 6, 5:31 pm, Howard Siegel hsie...@gmail.com wrote: If this has only been happening since this morning, then it is likely this is just part of the aftermath of the DOS attack on Twitter. - h On Thu, Aug 6, 2009 at 15:53, yuf kyl...@gmail.com wrote: I have yet to get oAuth callbacks to work properly. After clicking Allow, I end up on a completely blank twittter.com/oauth/authorize page. If I try to look at the source, it asked if should resend. If I do, the source comes back that contains the redirect. But if I'm not looking at the source, the page just hangs for a while, and then ends up blank. What is up here? I've tried a variety of callback urls, from localhost, to the actual domain I'm using for development. Any one experience similar?
[twitter-dev] Re: Why is Biz saying things are back in action?
+1 On Aug 6, 6:25 pm, Jesse Stay jesses...@gmail.com wrote: Why is Biz saying things are back in action when apps like mine, and many other very large names are still broken from it. Sending this message to users sends a false message to them stating they should expect we should be up as well. At a very minimum, please state the API is still having issues so users can know what to expect: http://blog.twitter.com/2009/08/update-on-todays-dos-attacks.html Jesse
[twitter-dev] OAuth question
Hi all, I am using twitter OAuth which works just fine, but I am not sure what exactly this means on the oauth signup page: Use Twitter for login:Yes, use Twitter for login Does your application intend to use Twitter for authentication? What happens if I check this box? Will there be something different or is this just an internal tracking for Twitter so they know what people intend to do? Cheers Sven
[twitter-dev] Re: OAuth question
thanx, good to know. I am also wondering about one thing: - if a user has authorized himself (using the authorize URL, not authenticate... will try that out later) and does the same process again, e.g. get's redirected to the authorize URL again, but with a new request token of course, he is AGAIN asked to sign in. I am not sure why, twitter could in this case just know that the user is signed in already. Also looking into the cookies, there is a twitter session established. It could be the default is just to show the login screen again... Or... is this the little difference between the authentication / authorization call. In this case authorization will always ask the user to sign in, and grant access to my app, but not keep the signed in user for the next call (which will not happen many times of course, most people just authorize once per session or even less). Instead, the authentication process truely detects a already present twitter session and will NOT ask the user to sign in even if he should be signed in already. Is that correct? Cheers Sven On Jul 21, 11:26 pm, Abraham Williams 4bra...@gmail.com wrote: Last I heard it changes nothing currently. There might be some features restricted to it in the future like using the faster oauth/authenticate method. Abraham On Wed, Jul 22, 2009 at 01:03, hansamann sven.hai...@googlemail.com wrote: Hi all, I am using twitter OAuth which works just fine, but I am not sure what exactly this means on the oauth signup page: Use Twitter for login: Yes, use Twitter for login Does your application intend to use Twitter for authentication? What happens if I check this box? Will there be something different or is this just an internal tracking for Twitter so they know what people intend to do? Cheers Sven -- Abraham Williams | Community Evangelist |http://web608.org Hacker |http://abrah.am|http://twitter.com/abraham Project |http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, WI, United States
