Re: [twitter-dev] Re: At Reply Spam
Dewald, These rules apply to third party apps. @twittersuggests is not a third party app, but an experimental feature, developed and owned by Twitter. Now I can also understand this Do as I Say, not as I Do situation can be irritating. But I guess the best thing to do at this point is probably to share your thoughts on the experiment through his dedicated feedback form: https://spreadsheets.google.com/a/twitter.com/spreadsheet/viewform?formkey=dHJ6UnYwdFZ6aHNRRVJoTU1mYl9FMlE6MQ Arnaud / @rno On May 5, 2011, at 11:56 AM, Dewald Pretorius dpr...@gmail.com wrote: Arnaud, That's comforting to know. With that being the case, can you please enlighten us as to why Twitter is apparently violating its own rules, which, as you said, are still in force and we all still are apparently expected to adhere to? Let me help you and quote from your rules the appropriate text: If you are automatically sending @reply messages or Mentions to a bunch of users, the recipients must request or approve this action in advance. Have any of the users targeted by @twittersuggests, which is sending automated @reply messages to a bunch of users, explicitly requested or approved this action in advance? If not, then you may have de facto invalidated that section of your rules and by implication exempted all developers and applications from it. On May 5, 12:45 pm, Arnaud Meunier arn...@twitter.com wrote: Hey Dewald, Neither our TOS nor our Automation Rules Best Practices (http://support.twitter.com/articles/76915) have changed since the launch of @twittersuggests experimental feature :) Arnaud / @rno http://twitter.com/rno On Thu, May 5, 2011 at 6:00 AM, TjL luo...@gmail.com wrote: On Thu, May 5, 2011 at 8:31 AM, Dewald Pretorius dpr...@gmail.com wrote: With reference to @twittersuggests, is other unsolicited @reply spam now also officially sanctioned by Twitter? When has Twitter ever given you the idea that they were playing by the same rules as everyone else? -- Twitter developer documentation and resources:http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Re: At Reply Spam
It's an @reply spambot, pure and simple. There is no vetting of suggested users - it didn't take either me or Marshall Kirkpatrick long to find a tweeter that was not safe for work in @twittersuggests' stream. It's a bad idea - Twitter needs to quit screwing around with stuff like this and solve problems that keep people with budgets up at night! On Fri, May 6, 2011 at 12:38 AM, Arnaud Meunier arn...@twitter.com wrote: Dewald, These rules apply to third party apps. @twittersuggests is not a third party app, but an experimental feature, developed and owned by Twitter. Now I can also understand this Do as I Say, not as I Do situation can be irritating. But I guess the best thing to do at this point is probably to share your thoughts on the experiment through his dedicated feedback form: https://spreadsheets.google.com/a/twitter.com/spreadsheet/viewform?formkey=dHJ6UnYwdFZ6aHNRRVJoTU1mYl9FMlE6MQ Arnaud / @rno On May 5, 2011, at 11:56 AM, Dewald Pretorius dpr...@gmail.com wrote: Arnaud, That's comforting to know. With that being the case, can you please enlighten us as to why Twitter is apparently violating its own rules, which, as you said, are still in force and we all still are apparently expected to adhere to? Let me help you and quote from your rules the appropriate text: If you are automatically sending @reply messages or Mentions to a bunch of users, the recipients must request or approve this action in advance. Have any of the users targeted by @twittersuggests, which is sending automated @reply messages to a bunch of users, explicitly requested or approved this action in advance? If not, then you may have de facto invalidated that section of your rules and by implication exempted all developers and applications from it. On May 5, 12:45 pm, Arnaud Meunier arn...@twitter.com wrote: Hey Dewald, Neither our TOS nor our Automation Rules Best Practices (http://support.twitter.com/articles/76915) have changed since the launch of @twittersuggests experimental feature :) Arnaud / @rno http://twitter.com/rno On Thu, May 5, 2011 at 6:00 AM, TjL luo...@gmail.com wrote: On Thu, May 5, 2011 at 8:31 AM, Dewald Pretorius dpr...@gmail.com wrote: With reference to @twittersuggests, is other unsolicited @reply spam now also officially sanctioned by Twitter? When has Twitter ever given you the idea that they were playing by the same rules as everyone else? -- Twitter developer documentation and resources:http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- http://twitter.com/znmeb http://borasky-research.net A mathematician is a device for turning coffee into theorems. -- Paul Erdős -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Re: At Reply Spam
Arnaud, Know what I totally cannot understand? Why is it that Twitter, through various spokespersons, continually reinforces the impression that they pay scant lip service to the alleged notion that they value the third party developer ecosystem? Under any circumstances, Do as I say, not as I do, is disrespectful and demonstrates that the intended audience of that approach is viewed by the perpetrators of the approach as occupying a lower and less privileged strata of society. It is disrespectful when you treat your kids that way. It is disrespectful when you treat your life partner that way. It is disrespectful when you treat your business partners that way. Does Twitter like pointing a loaded gun at its own foot and pulling the trigger, again and again? On May 6, 4:38 am, Arnaud Meunier arn...@twitter.com wrote: Dewald, These rules apply to third party apps. @twittersuggests is not a third party app, but an experimental feature, developed and owned by Twitter. Now I can also understand this Do as I Say, not as I Do situation can be irritating. But I guess the best thing to do at this point is probably to share your thoughts on the experiment through his dedicated feedback form:https://spreadsheets.google.com/a/twitter.com/spreadsheet/viewform?fo... Arnaud / @rno On May 5, 2011, at 11:56 AM, Dewald Pretorius dpr...@gmail.com wrote: Arnaud, That's comforting to know. With that being the case, can you please enlighten us as to why Twitter is apparently violating its own rules, which, as you said, are still in force and we all still are apparently expected to adhere to? Let me help you and quote from your rules the appropriate text: If you are automatically sending @reply messages or Mentions to a bunch of users, the recipients must request or approve this action in advance. Have any of the users targeted by @twittersuggests, which is sending automated @reply messages to a bunch of users, explicitly requested or approved this action in advance? If not, then you may have de facto invalidated that section of your rules and by implication exempted all developers and applications from it. On May 5, 12:45 pm, Arnaud Meunier arn...@twitter.com wrote: Hey Dewald, Neither our TOS nor our Automation Rules Best Practices (http://support.twitter.com/articles/76915) have changed since the launch of @twittersuggests experimental feature :) Arnaud / @rno http://twitter.com/rno On Thu, May 5, 2011 at 6:00 AM, TjL luo...@gmail.com wrote: On Thu, May 5, 2011 at 8:31 AM, Dewald Pretorius dpr...@gmail.com wrote: With reference to @twittersuggests, is other unsolicited @reply spam now also officially sanctioned by Twitter? When has Twitter ever given you the idea that they were playing by the same rules as everyone else? -- Twitter developer documentation and resources:http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources:http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker:http://code.google.com/p/twitter-api/issues/list Change your membership to this group:http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
RE: [twitter-dev] Re: At Reply Spam
Arnaud, If you guys want a suggestion on what Twitter should be working on then my list would include things that corporates would actually want to pay money for including analytics and analysis on who is viewing my tweets. The day Twitter pony up and start allowing paid accounts is the day I know their serious. Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-talk@googlegroups.com] On Behalf Of M. Edward (Ed) Borasky Sent: Friday, May 06, 2011 4:12 AM To: twitter-development-talk@googlegroups.com Cc: dpr...@gmail.com Subject: Re: [twitter-dev] Re: At Reply Spam It's an @reply spambot, pure and simple. There is no vetting of suggested users - it didn't take either me or Marshall Kirkpatrick long to find a tweeter that was not safe for work in @twittersuggests' stream. It's a bad idea - Twitter needs to quit screwing around with stuff like this and solve problems that keep people with budgets up at night! On Fri, May 6, 2011 at 12:38 AM, Arnaud Meunier arn...@twitter.com wrote: Dewald, These rules apply to third party apps. @twittersuggests is not a third party app, but an experimental feature, developed and owned by Twitter. Now I can also understand this Do as I Say, not as I Do situation can be irritating. But I guess the best thing to do at this point is probably to share your thoughts on the experiment through his dedicated feedback form: https://spreadsheets.google.com/a/twitter.com/spreadsheet/viewform?formkey=dHJ6UnYwdFZ6aHNRRVJoTU1mYl9FMlE6MQ Arnaud / @rno On May 5, 2011, at 11:56 AM, Dewald Pretorius dpr...@gmail.com wrote: Arnaud, That's comforting to know. With that being the case, can you please enlighten us as to why Twitter is apparently violating its own rules, which, as you said, are still in force and we all still are apparently expected to adhere to? Let me help you and quote from your rules the appropriate text: If you are automatically sending @reply messages or Mentions to a bunch of users, the recipients must request or approve this action in advance. Have any of the users targeted by @twittersuggests, which is sending automated @reply messages to a bunch of users, explicitly requested or approved this action in advance? If not, then you may have de facto invalidated that section of your rules and by implication exempted all developers and applications from it. On May 5, 12:45 pm, Arnaud Meunier arn...@twitter.com wrote: Hey Dewald, Neither our TOS nor our Automation Rules Best Practices (http://support.twitter.com/articles/76915) have changed since the launch of @twittersuggests experimental feature :) Arnaud / @rno http://twitter.com/rno On Thu, May 5, 2011 at 6:00 AM, TjL luo...@gmail.com wrote: On Thu, May 5, 2011 at 8:31 AM, Dewald Pretorius dpr...@gmail.com wrote: With reference to @twittersuggests, is other unsolicited @reply spam now also officially sanctioned by Twitter? When has Twitter ever given you the idea that they were playing by the same rules as everyone else? -- Twitter developer documentation and resources:http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- http://twitter.com/znmeb http://borasky-research.net A mathematician is a device for turning coffee into theorems. -- Paul Erdős -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Re: At Reply Spam
Arnaud, That's comforting to know. With that being the case, can you please enlighten us as to why Twitter is apparently violating its own rules, which, as you said, are still in force and we all still are apparently expected to adhere to? Let me help you and quote from your rules the appropriate text: If you are automatically sending @reply messages or Mentions to a bunch of users, the recipients must request or approve this action in advance. Have any of the users targeted by @twittersuggests, which is sending automated @reply messages to a bunch of users, explicitly requested or approved this action in advance? If not, then you may have de facto invalidated that section of your rules and by implication exempted all developers and applications from it. On May 5, 12:45 pm, Arnaud Meunier arn...@twitter.com wrote: Hey Dewald, Neither our TOS nor our Automation Rules Best Practices (http://support.twitter.com/articles/76915) have changed since the launch of @twittersuggests experimental feature :) Arnaud / @rno http://twitter.com/rno On Thu, May 5, 2011 at 6:00 AM, TjL luo...@gmail.com wrote: On Thu, May 5, 2011 at 8:31 AM, Dewald Pretorius dpr...@gmail.com wrote: With reference to @twittersuggests, is other unsolicited @reply spam now also officially sanctioned by Twitter? When has Twitter ever given you the idea that they were playing by the same rules as everyone else? -- Twitter developer documentation and resources:http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Re: At Reply Spam
On Thu, May 5, 2011 at 2:56 PM, Dewald Pretorius dpr...@gmail.com wrote: If not, then you may have de facto invalidated that section of your rules and by implication exempted all developers and applications from it. HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA. Um… Yeah. Here's the thing: it's Twitter's playground. They can do whatever they want with it. Just because they do it, doesn't mean you can do it. I don't know what sort of universal, nature law you think applies here, but it doesn't. TjL -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] Re: At Reply Spam
+1 It is Twitter's ball. On 5 May 2011, at 20:04, TjL wrote: On Thu, May 5, 2011 at 2:56 PM, Dewald Pretorius dpr...@gmail.com wrote: If not, then you may have de facto invalidated that section of your rules and by implication exempted all developers and applications from it. HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA. Um… Yeah. Here's the thing: it's Twitter's playground. They can do whatever they want with it. Just because they do it, doesn't mean you can do it. I don't know what sort of universal, nature law you think applies here, but it doesn't. TjL -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
[twitter-dev] Re: In Reply To
For example - make a script which tracks a specific #hashtag you are required to include to be in the chain, then each time it is mentioned harvest the in reply to from that tag and keep it in a database which can then be used to access that tweet later... A rather roundabout way but will work i guess. On Aug 6, 8:48 am, gloopymoop nerdf...@gmail.com wrote: Thankyou for your reply. I'm a little unsure as to how the streaming API method would work.. can you give me an example ? I would still have to create a local database of the chain, right? On Aug 6, 3:58 am, David dtran...@gmail.com wrote: Hey gloopymoop, Like the original thread said, you can use the search API to search for tweets to that particular user and check the in_reply_to_status_id field. If you want to track the chain (ie all the replies to @dtran320's reply to @gloopymoop's original tweet), then you have to periodically search each user in the chain. A more efficient way of achieving this would be to use the Track or Follow streaming API methods and add one users as they join the reply chain:http://dev.twitter.com/pages/streaming_api_methods#follow On Aug 3, 6:49 pm, gloopymoop nerdf...@gmail.com wrote: I believe this has been discussed before here, so forgive me if this is redundant. http://groups.google.com/group/twitter-development-talk/browse_thread... I would like to build a chain of replies originating from a single tweet. The user will look at the first tweet, then be presented with the replies to this tweet and be able to move along the chain from the head down the branches. What would be the best way of implementing this? Requiring users to include a hashtag then periodically searching and keeping a local database of which tweets are in_reply_to which?
[twitter-dev] Re: In Reply To
Hey gloopymoop, Like the original thread said, you can use the search API to search for tweets to that particular user and check the in_reply_to_status_id field. If you want to track the chain (ie all the replies to @dtran320's reply to @gloopymoop's original tweet), then you have to periodically search each user in the chain. A more efficient way of achieving this would be to use the Track or Follow streaming API methods and add one users as they join the reply chain: http://dev.twitter.com/pages/streaming_api_methods#follow On Aug 3, 6:49 pm, gloopymoop nerdf...@gmail.com wrote: I believe this has been discussed before here, so forgive me if this is redundant. http://groups.google.com/group/twitter-development-talk/browse_thread... I would like to build a chain of replies originating from a single tweet. The user will look at the first tweet, then be presented with the replies to this tweet and be able to move along the chain from the head down the branches. What would be the best way of implementing this? Requiring users to include a hashtag then periodically searching and keeping a local database of which tweets are in_reply_to which?
[twitter-dev] Re: In Reply To
Thankyou for your reply. I'm a little unsure as to how the streaming API method would work.. can you give me an example ? I would still have to create a local database of the chain, right? On Aug 6, 3:58 am, David dtran...@gmail.com wrote: Hey gloopymoop, Like the original thread said, you can use the search API to search for tweets to that particular user and check the in_reply_to_status_id field. If you want to track the chain (ie all the replies to @dtran320's reply to @gloopymoop's original tweet), then you have to periodically search each user in the chain. A more efficient way of achieving this would be to use the Track or Follow streaming API methods and add one users as they join the reply chain:http://dev.twitter.com/pages/streaming_api_methods#follow On Aug 3, 6:49 pm, gloopymoop nerdf...@gmail.com wrote: I believe this has been discussed before here, so forgive me if this is redundant. http://groups.google.com/group/twitter-development-talk/browse_thread... I would like to build a chain of replies originating from a single tweet. The user will look at the first tweet, then be presented with the replies to this tweet and be able to move along the chain from the head down the branches. What would be the best way of implementing this? Requiring users to include a hashtag then periodically searching and keeping a local database of which tweets are in_reply_to which?
[twitter-dev] Re: Empty reply from server on Streaming API?
Just to close the loop on my issue: I got some off-list help, Twitter investigated, and it turns out my IP address had been blacklisted in error. The blacklisting is removed, and I'm back in business. I must say it's nice that I could ask a question on this list, and get pretty much immediate attention from the proper Twitter person, and over a weekend at that. Thanks, John Kalucki, and thanks, Twitter. --Jim DeLaHunt, Vancouver, Canada@jdlh http://jdlh.com/en/pr/twanguages.html Twanguages: a language census of Twitter @twanguages On Nov 15, 6:52 am, John Kalucki jkalu...@gmail.com wrote: There are two levels of blacklisting. One is a temporary band that resets every few minutes. This one gives you 401 errors. Then there's an IP black hole that is removed by an operator. Currently the IP black hole sends a TCP RST, but we might might also null route you. You can verify an IP block by attempting to connect from a different network. If you provide an account name, I can look through the logs and see what happened. An IP address can also be helpful. In the absence of these keys, I can only speculate as to what occurred. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Nov 15, 12:54 am, Jim DeLaHunt jim.delah...@gmail.com wrote: John: Thanks very much for the reply. On Nov 14, 8:30 pm, John Kalucki jkalu...@gmail.com wrote: This sounds like you were ignoring HTTP error codes and eventually got blacklisted. Consider:http://apiwiki.twitter.com/Streaming-API-Documentation#Connecting Hmm... I was launching single curl requests, making one connection then breaking it after max 3 seconds. I would then wait 6 minutes before trying to connect again. I didn't record the HTTP result code I got back, but it seems that according to Streaming-API- Documentation#Connecting I was being tremendously conservative. That doc recommends backing off for 10 to 240 seconds on an HTTP error code (200); I always backed off for 360 seconds immediately, whether the HTTP error code was good or bad. How would backing off by *more* than the docs call for get me blacklisted? You can tell for sure by turning off --silent and using -v to see what's going on. You should be getting some sort of message back, or absolutely nothing back. Those codes are not HTTP error codes, they must be some curl artifact. Correct, the codes 6 and 52 are defined by curl. Seehttp://curl.haxx.se/docs/manpage.html. Using -v and other curl options, I see clearly that what I'm getting back is absolutely nothing back: 0 bytes in response to my HTTP query. (That's the meaning of the code 52.) For the last 6 hours, I've polled once per hour (once per 3600 seconds), and this null response has not changed. The docs don't say how to confirm that I've been blacklisted. Any suggestions for how to confirm that? Nor do they say what to do if I am in fact blacklisted. They say that the blacklist lasts an indeterminate period of time, so maybe they are implying I should just wait and the system will list the blacklist itself. The biggest issue, though, is to understand why I could have become blacklisted, when I backed off for 360 seconds after each attempt. Because right now, I don't know what I should do differently. Thanks again for the guidance. --Jim DeLaHunt, Vancouver, Canada �...@jdlh Twanguages: a language census of Twitter @twanguageshttp://jdlh.com/en/pr/twanguages.html Tcpdump is also sometimes useful. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Nov 14, 6:13 pm, Jim DeLaHunt jim.delah...@gmail.com wrote: Am I the only one seeing this? I call the Streaming API 10x/hour. For the last 23 hours or so, I've been getting bad responses every time. I use a cron job to call from the Linux shell: curl --user myid:mypassword --silent --fail --max-time 3 --retry 0http://stream.twitter.com/1/statuses/sample.xml and I get usually a curl return code (52) Empty reply from server, though sometimes (6) name lookup timed out. Same thing happens when I ask for .json instead of .xml. The failures started at the rate of 1-2/hour on 2009/11/13 09:00h UTC (Friday early morning PST), though they became continuous as of 200/11/14 03:24h UTC (Friday evening PST), and remain continuous. Is anyone else calling this API and failing? Or succeeding? in the last 24 hours? Thank you, --Jim DeLaHunt, Vancouver, Canada �...@jdlh Twanguages: a language census of Twitter @twanguageshttp://jdlh.com/en/pr/twanguages.html
[twitter-dev] Re: Empty reply from server on Streaming API?
John: Thanks very much for the reply. On Nov 14, 8:30 pm, John Kalucki jkalu...@gmail.com wrote: This sounds like you were ignoring HTTP error codes and eventually got blacklisted. Consider:http://apiwiki.twitter.com/Streaming-API-Documentation#Connecting Hmm... I was launching single curl requests, making one connection then breaking it after max 3 seconds. I would then wait 6 minutes before trying to connect again. I didn't record the HTTP result code I got back, but it seems that according to Streaming-API- Documentation#Connecting I was being tremendously conservative. That doc recommends backing off for 10 to 240 seconds on an HTTP error code (200); I always backed off for 360 seconds immediately, whether the HTTP error code was good or bad. How would backing off by *more* than the docs call for get me blacklisted? You can tell for sure by turning off --silent and using -v to see what's going on. You should be getting some sort of message back, or absolutely nothing back. Those codes are not HTTP error codes, they must be some curl artifact. Correct, the codes 6 and 52 are defined by curl. See http://curl.haxx.se/docs/manpage.html . Using -v and other curl options, I see clearly that what I'm getting back is absolutely nothing back: 0 bytes in response to my HTTP query. (That's the meaning of the code 52.) For the last 6 hours, I've polled once per hour (once per 3600 seconds), and this null response has not changed. The docs don't say how to confirm that I've been blacklisted. Any suggestions for how to confirm that? Nor do they say what to do if I am in fact blacklisted. They say that the blacklist lasts an indeterminate period of time, so maybe they are implying I should just wait and the system will list the blacklist itself. The biggest issue, though, is to understand why I could have become blacklisted, when I backed off for 360 seconds after each attempt. Because right now, I don't know what I should do differently. Thanks again for the guidance. --Jim DeLaHunt, Vancouver, Canada@jdlh Twanguages: a language census of Twitter @twanguages http://jdlh.com/en/pr/twanguages.html Tcpdump is also sometimes useful. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Nov 14, 6:13 pm, Jim DeLaHunt jim.delah...@gmail.com wrote: Am I the only one seeing this? I call the Streaming API 10x/hour. For the last 23 hours or so, I've been getting bad responses every time. I use a cron job to call from the Linux shell: curl --user myid:mypassword --silent --fail --max-time 3 --retry 0http://stream.twitter.com/1/statuses/sample.xml and I get usually a curl return code (52) Empty reply from server, though sometimes (6) name lookup timed out. Same thing happens when I ask for .json instead of .xml. The failures started at the rate of 1-2/hour on 2009/11/13 09:00h UTC (Friday early morning PST), though they became continuous as of 200/11/14 03:24h UTC (Friday evening PST), and remain continuous. Is anyone else calling this API and failing? Or succeeding? in the last 24 hours? Thank you, --Jim DeLaHunt, Vancouver, Canada �...@jdlh Twanguages: a language census of Twitter @twanguageshttp://jdlh.com/en/pr/twanguages.html
[twitter-dev] Re: Empty reply from server on Streaming API?
I had the same issue. And i was blacklisted. On 11/15/09, Jim DeLaHunt jim.delah...@gmail.com wrote: John: Thanks very much for the reply. On Nov 14, 8:30 pm, John Kalucki jkalu...@gmail.com wrote: This sounds like you were ignoring HTTP error codes and eventually got blacklisted. Consider:http://apiwiki.twitter.com/Streaming-API-Documentation#Connecting Hmm... I was launching single curl requests, making one connection then breaking it after max 3 seconds. I would then wait 6 minutes before trying to connect again. I didn't record the HTTP result code I got back, but it seems that according to Streaming-API- Documentation#Connecting I was being tremendously conservative. That doc recommends backing off for 10 to 240 seconds on an HTTP error code (200); I always backed off for 360 seconds immediately, whether the HTTP error code was good or bad. How would backing off by *more* than the docs call for get me blacklisted? You can tell for sure by turning off --silent and using -v to see what's going on. You should be getting some sort of message back, or absolutely nothing back. Those codes are not HTTP error codes, they must be some curl artifact. Correct, the codes 6 and 52 are defined by curl. See http://curl.haxx.se/docs/manpage.html . Using -v and other curl options, I see clearly that what I'm getting back is absolutely nothing back: 0 bytes in response to my HTTP query. (That's the meaning of the code 52.) For the last 6 hours, I've polled once per hour (once per 3600 seconds), and this null response has not changed. The docs don't say how to confirm that I've been blacklisted. Any suggestions for how to confirm that? Nor do they say what to do if I am in fact blacklisted. They say that the blacklist lasts an indeterminate period of time, so maybe they are implying I should just wait and the system will list the blacklist itself. The biggest issue, though, is to understand why I could have become blacklisted, when I backed off for 360 seconds after each attempt. Because right now, I don't know what I should do differently. Thanks again for the guidance. --Jim DeLaHunt, Vancouver, Canada@jdlh Twanguages: a language census of Twitter @twanguages http://jdlh.com/en/pr/twanguages.html Tcpdump is also sometimes useful. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Nov 14, 6:13 pm, Jim DeLaHunt jim.delah...@gmail.com wrote: Am I the only one seeing this? I call the Streaming API 10x/hour. For the last 23 hours or so, I've been getting bad responses every time. I use a cron job to call from the Linux shell: curl --user myid:mypassword --silent --fail --max-time 3 --retry 0http://stream.twitter.com/1/statuses/sample.xml and I get usually a curl return code (52) Empty reply from server, though sometimes (6) name lookup timed out. Same thing happens when I ask for .json instead of .xml. The failures started at the rate of 1-2/hour on 2009/11/13 09:00h UTC (Friday early morning PST), though they became continuous as of 200/11/14 03:24h UTC (Friday evening PST), and remain continuous. Is anyone else calling this API and failing? Or succeeding? in the last 24 hours? Thank you, --Jim DeLaHunt, Vancouver, Canada �...@jdlh Twanguages: a language census of Twitter @twanguageshttp://jdlh.com/en/pr/twanguages.html -- Sent from my mobile device A K M Mokaddim http://talk.cmyweb.net http://twitter.com/shiplu Stop Top Posting !! বাংলিশ লেখার চাইতে বাংলা লেখা অনেক ভাল
[twitter-dev] Re: Empty reply from server on Streaming API?
There are two levels of blacklisting. One is a temporary band that resets every few minutes. This one gives you 401 errors. Then there's an IP black hole that is removed by an operator. Currently the IP black hole sends a TCP RST, but we might might also null route you. You can verify an IP block by attempting to connect from a different network. If you provide an account name, I can look through the logs and see what happened. An IP address can also be helpful. In the absence of these keys, I can only speculate as to what occurred. -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Nov 15, 12:54 am, Jim DeLaHunt jim.delah...@gmail.com wrote: John: Thanks very much for the reply. On Nov 14, 8:30 pm, John Kalucki jkalu...@gmail.com wrote: This sounds like you were ignoring HTTP error codes and eventually got blacklisted. Consider:http://apiwiki.twitter.com/Streaming-API-Documentation#Connecting Hmm... I was launching single curl requests, making one connection then breaking it after max 3 seconds. I would then wait 6 minutes before trying to connect again. I didn't record the HTTP result code I got back, but it seems that according to Streaming-API- Documentation#Connecting I was being tremendously conservative. That doc recommends backing off for 10 to 240 seconds on an HTTP error code (200); I always backed off for 360 seconds immediately, whether the HTTP error code was good or bad. How would backing off by *more* than the docs call for get me blacklisted? You can tell for sure by turning off --silent and using -v to see what's going on. You should be getting some sort of message back, or absolutely nothing back. Those codes are not HTTP error codes, they must be some curl artifact. Correct, the codes 6 and 52 are defined by curl. Seehttp://curl.haxx.se/docs/manpage.html. Using -v and other curl options, I see clearly that what I'm getting back is absolutely nothing back: 0 bytes in response to my HTTP query. (That's the meaning of the code 52.) For the last 6 hours, I've polled once per hour (once per 3600 seconds), and this null response has not changed. The docs don't say how to confirm that I've been blacklisted. Any suggestions for how to confirm that? Nor do they say what to do if I am in fact blacklisted. They say that the blacklist lasts an indeterminate period of time, so maybe they are implying I should just wait and the system will list the blacklist itself. The biggest issue, though, is to understand why I could have become blacklisted, when I backed off for 360 seconds after each attempt. Because right now, I don't know what I should do differently. Thanks again for the guidance. --Jim DeLaHunt, Vancouver, Canada �...@jdlh Twanguages: a language census of Twitter @twanguageshttp://jdlh.com/en/pr/twanguages.html Tcpdump is also sometimes useful. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Nov 14, 6:13 pm, Jim DeLaHunt jim.delah...@gmail.com wrote: Am I the only one seeing this? I call the Streaming API 10x/hour. For the last 23 hours or so, I've been getting bad responses every time. I use a cron job to call from the Linux shell: curl --user myid:mypassword --silent --fail --max-time 3 --retry 0http://stream.twitter.com/1/statuses/sample.xml and I get usually a curl return code (52) Empty reply from server, though sometimes (6) name lookup timed out. Same thing happens when I ask for .json instead of .xml. The failures started at the rate of 1-2/hour on 2009/11/13 09:00h UTC (Friday early morning PST), though they became continuous as of 200/11/14 03:24h UTC (Friday evening PST), and remain continuous. Is anyone else calling this API and failing? Or succeeding? in the last 24 hours? Thank you, --Jim DeLaHunt, Vancouver, Canada �...@jdlh Twanguages: a language census of Twitter @twanguageshttp://jdlh.com/en/pr/twanguages.html
[twitter-dev] Re: in reply to links no longer appears in web interface
OK, just checked this morning and in reply to links are back on the website! Thanks for fixing the bug, twitter team! =) On Nov 13, 2:00 pm, bassmanjase jase.mitch...@gmail.com wrote: Hi, I use twitter (@bassmanjase), and access it via the website and teh Echofon plugin for Firefox. I've just noticed today that the in reply to links no longer appear on the website, but they're still present in Echofon. It's possible that this change happened at the same time as the ReTweet upgrade - I saw the popup on my twitter home-page just a couple of days ago. I thought I'd mention it, since being able to see who someone is replying to is kind of helpful, esp since I have the bit.ly plugin installed which shows the original tweet when I hover over in reply to. I can't do that any more, since the link is no longer there. There are quite a few users with this problem - just twitter-search in reply to and you'll get a decent number of hits. Cheers, Bassmanjase.
[twitter-dev] Re: Empty reply from server on Streaming API?
This sounds like you were ignoring HTTP error codes and eventually got blacklisted. Consider: http://apiwiki.twitter.com/Streaming-API-Documentation#Connecting You can tell for sure by turning off --silent and using -v to see what's going on. You should be getting some sort of message back, or absolutely nothing back. Those codes are not HTTP error codes, they must be some curl artifact. Tcpdump is also sometimes useful. -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Nov 14, 6:13 pm, Jim DeLaHunt jim.delah...@gmail.com wrote: Am I the only one seeing this? I call the Streaming API 10x/hour. For the last 23 hours or so, I've been getting bad responses every time. I use a cron job to call from the Linux shell: curl --user myid:mypassword --silent --fail --max-time 3 --retry 0http://stream.twitter.com/1/statuses/sample.xml and I get usually a curl return code (52) Empty reply from server, though sometimes (6) name lookup timed out. Same thing happens when I ask for .json instead of .xml. The failures started at the rate of 1-2/hour on 2009/11/13 09:00h UTC (Friday early morning PST), though they became continuous as of 200/11/14 03:24h UTC (Friday evening PST), and remain continuous. Is anyone else calling this API and failing? Or succeeding? in the last 24 hours? Thank you, --Jim DeLaHunt, Vancouver, Canada �...@jdlh Twanguages: a language census of Twitter @twanguageshttp://jdlh.com/en/pr/twanguages.html
[twitter-dev] Re: reading reply status post
On Fri, Nov 6, 2009 at 12:28 PM, MuratMetu muratm...@yahoo.com wrote: Hello, I am new to twitter dev, is there any way to read replies posted to my account from api like @MyUsername ..? Status request reads only the statuses. I want to do it from Twitter API not from 3. party Check out this cool site: http://apiwiki.twitter.com/Twitter-API-Documentation -damon
[twitter-dev] Re: in reply to metadata missing for manual replies
I'm adding my opinion to this thread after a little bit of back-and- forth with @simX and @KuraFire on Twitter the other day. 140 characters is just not enough to convey a complete argument. This change of functionality has turned a feature that was in a definite gray area, to black and white. The application is no longer assuming a user's intentions (possibly incorrectly), but requiring them to assign the additional data if they wish. Yes, it takes additional effort to create additional information, but saving and displaying assumed-to-be-correct information as fact is wrong. When you create a new message in Apple Mail (or any other mainstream mail client I'm aware of) it is not automatically marked as a reply to the last message you received. You have to specify which message you are replying to, and have the choice to start a new thread by replying to nothing at all. Your solution does not provide this as an option. All messages prefixed by a username will be treated like a reply with no way to opt-out. Your suggestion to include multiple posts on all an individual status pages is conventionally incorrect. A direct link should only show one status: the one you asked for. However, Twitter could take advantage of the 100% accurate metadata present in the new reply functionality and create conversation pages showing the thread. This, and any other application taking advantage of the metadata, would be broken if it contained the false positives your solution introduces. Travis Dent @tcdent
[twitter-dev] Re: in reply to metadata missing for manual replies
So your argument of mouse vs keyboard use doesn't even convince ME, an avid keyboard user. I like it how I'm supposed to be the one that's an uninformed idiot, except for the fact that I actually use the Twitter website daily, and I can tell you that simply typing @name is faster than having to click a reply swoosh, especially since the website's text field is automatically focused when the page is loaded. Like I said, I *use* the reply swooshes *myself* because I like to get the accurate metadata, too! What part of I understand the benefits, I just want the benefits of the old way as well is hard to understand? Instead you just want to add extra unnecessary metadata and then have programmers try to guess what the original intention was. Thanks for completely misunderstanding what I'm trying to point out. Programmers need not do guesswork at all. Programmers can leave it up to the user to decide whether a tweet is a genuine reply or not, because the user is the best-equipped to figure this out. Users can use whether a reply was specifically linked by the twitterer or if it was automatically linked by Twitter, and they can use the text of the linked tweet to figure it out, too. And what AI are they going to use to determine whether this extra metadata or lack thereof means that this is an actualreply? They're going to go whichever they prefer. *facepalm* There is no AI involved. The point is to equip the user with as much information as possible to determine the context of the tweet. Even approximate context is better than none. Meaning that they are going to get a different result for 'conversations' depending on whether they use Summize (which is going to have to choose one method) or some other client. Yes, that's right, depending on whether the client or the app in particular is dependent upon extremely accurate twitter conversation links (like, for example, conversation-trackers like the now-defunct Quotably), or if they just want the user to be able to figure out more information about the topic in question (such as most Twitter clients). The only different result that will occur is that those who wish to use the approximate data will have longer conversations that may or may not be accurate. But they will be a complete superset of the shorter, exact conversations that use the exact in_reply_to data. Users can easily figure out when the approximate context is wrong in the course of scanning such data, far faster than any AI that I'm supposedly advocating for. I'm just not convinced by it. Please provide a way to easily figure out which tweet this is in response to, given the new policy of Twitter to not auto-link manual replies: http://twitter.com/KuraFire/status/1176556069 . Until you do, I am unconvinced that *you* understand the complete exercise in *utter* frustration the new feature has caused in trying to follow some conversations.
[twitter-dev] Re: in reply to metadata missing for manual replies
Back and forth with atebits over e-mail: I, personally, found the false positives much more acceptable than the current situation where you have to hunt for originating tweets for false negatives. Doing anything interesting like automatically crawling conversation webs is flat out impossible with false positives, and only an annoyance with false negatives. It is a lie that it is impossible with false positives. With false positives, you can *always* crawl all conversation webs when they are correct, even when auto-linked, and you can easily tell when the auto- linking targeted an incorrect tweet. With false negatives, it's a lot worse because sometimes you can't crawl a correct conversation web at all. It is *far* faster for a user to identify a false positive then a user to hunt for a false negative. Again, it takes 1 second to identify that the auto-linking was incorrect, but 10 seconds to MINUTES to find the correct reply to a false negative, especially if the user is a prolific tweeter. Again, the new in_reply_to_status_id is relatively new, so with most people using that, the conversation webs will largely be correct. But when someone forgets to use the reply swoosh, I'd rather have Twitter auto-link the reply even if it causes some conversation webs to be falsely connected. I would also argue that false negatives should be blamed on crappy clients. I know that a few clients (up until recently) didn't set the in_reply_to_status_id AT ALL, even for tweets where the user *explicitly* replies to a particular tweet (i.e. clicked the reply button next to it). I'm sorry, but also no. I have seen many people who are using conforming clients not jump through the UI hoops to perform a correct reply, both out of habit (i.e.: constant violators), or out of error (i.e.: just a one-time mistake). I prefer to take both kinds of human error out of the question via auto-linking. The false negatives were caused by people not used to the fact that they have to perform additional UI actions because of the change. To force users to do something to get a correct reply is stupid, in contrast to letting them do what they naturally do (which is how it was before). There will be some growing pains, which will last as long as people continue to use crappy clients. After that, many really interesting things become possible. No, again, people are already using conforming clients. And, no, again, even with false positives, really interesting things are *already* possible. False positives do not inhibit any of those really interesting things. That sounds rather hackish. I think the correct long term solution is to leave it exactly as-is. The other thing I'd like to point out is that with the old system, there was no way to express a general reply. By that I mean a reply to someone that *isn't* in response to a particular tweet... more of just a directed tweet - which is a legitimately useful thing to express (and I'm not sure how you would express it using your workaround). *facepalm* I am well aware that you couldn't express a general reply with the old system. Stop convincing yourself that I'm advocating to go back to the old way. With my way, you do it exactly as you do it now, and as you did it before: you simply type in @atebits and then your message. Twitter will auto-link it, and then display the link if the user's prefs say to display auto-links. The user can figure out whether the context is correct or not. The point is that humans are much more capable of determining whether context is correct or not, but computers are far better at establishing any sort of context in the first place. So the most effective way to establish the best context is to let both computers and humans do what they are best at doing. Computers will provide as much context as possible, and humans will throw out the context that isn't good. -- Simone
[twitter-dev] Re: in reply to metadata missing for manual replies
On Wed, Mar 4, 2009 at 4:38 PM, atebits loren.brich...@gmail.com wrote: 1. If a client is making users jump through hoops to reply to a specific tweet, the client is doing it wrong. [snip] The end of auto-linking was a fantastic change for two reasons: 1. it keeps everything simple (no new settings or flags or functionality), 2. it allows developers to trust in_reply_to_status_id, paving the way for some *really* fantastic stuff down the road. Agreed on both points. I like the possibilities for actual conversation threading (not yet realized in summize searches but you can see the potential) With the exception that m.twitter.com really needs to get a reply button that works properly. If people are too lazy, well... tough. Just like proper mail filtering/threading, if they can't be bothered to figure out how it works, they'll lose some of the advantages that the software can provide for them. If they are using outdated software, then all sorts of things may break, including favorites (broken in an earlier version of Twitterrific when the API changed). Again, tough. There *should* be a way to start a conversation chain without setting an in-reply-to being added where it doesn't belong. That's where it makes sense that you would type in @NAME by hand. Twitter shouldn't be held hostage to the way it used to be for a feature which was clearly broken by indicating a relationship between two posts when there was none. Neither should they be held hostage to Users are too lazy to do it the right way. And yes, if their twitter client makes real replies too hard, they should be updated to make it easier or they should fall into disuse. TjL
[twitter-dev] Re: in reply to metadata missing for manual replies
On 4 Mar, 14:25, TjL luo...@gmail.com wrote: There *should* be a way to start a conversation chain without setting an in-reply-to being added where it doesn't belong. That's where it makes sense that you would type in @NAME by hand. Twitter shouldn't be held hostage to the way it used to be for a feature which was clearly broken by indicating a relationship between two posts when there was none. Neither should they be held hostage to Users are too lazy to do it the right way. As I have attempted to explain to atebits and to others, I AM NOT ADVOCATING TO GO BACK TO THE WAY IT USED TO BE. I am advocating for a *compromise* solution. I *understand* the need for there to be an accurate way to follow conversation chains, and I *like* that the new way allows for this. But the approximate context that the previous method used should *also* NOT be tossed out. If an extra flag is set in addition to the in_reply_to_status_id metadata, then BOTH methods can be used. Clients which want to throw out any non-exact context can accept only that data which includes the exact flag, and clients which want as much context as possible can simply ignore the flag. BOTH METHODS CAN BE DONE AT ONCE. And yes, if their twitter client makes real replies too hard, they should be updated to make it easier or they should fall into disuse. This is just arrogant. This is completely false. When someone wants to reply to me, typing five characters, @simX is *far* faster than moving your mouse to target a tiny little reply swoosh. It takes a whole second to move your hand to the mouse, when you can type those 5 characters in under a second if you're a fast typer. Saying that users who refuse to jump through the UI hoops are somehow inferior is lame and condescending. Not only that, but humans often make mistakes and simply forget to target a specific tweet. Losing the context because of simple human error is unnecessary. The @reply syntax was created organically by users. It was not created by Twitter. As such, it represents more of how users actually want to interact with Twitter. That functionality should be preserved AS WELL AS providing a way to accurately follow conversation chains. The mere fact that there are genuine replies that don't have the in_reply_to_status_id metadata set demonstrates that the new interface should not completely replace the old functionality. -- Simone
[twitter-dev] Re: in reply to metadata missing for manual replies
When is this problem going to get fixed? 1.5 months after the original API change, I am still getting a significant portion of replies in my timeline that are supposed to be *to a specific tweet*, but are not because Twitter is no longer auto-linking manual @replies and people are lazy and don't want to take the time in the interface of their client to correctly reply to a tweet. Note: user laziness is *not* a failure on the part of the user, this is a failure on the part of Twitter. Requiring a user to go through a specific part of the UI just to reply to a tweet is not acceptable. When is a viable compromise solution going to get implemented so that @replies become tolerable again?
[twitter-dev] Re: in reply to metadata missing for manual replies
Just curious, of these replies that *should* be linked to a specific tweet, how many are coming from web and how many from another application ? -Chad On Tue, Mar 3, 2009 at 7:04 PM, simX simsimb...@gmail.com wrote: When is this problem going to get fixed? 1.5 months after the original API change, I am still getting a significant portion of replies in my timeline that are supposed to be *to a specific tweet*, but are not because Twitter is no longer auto-linking manual @replies and people are lazy and don't want to take the time in the interface of their client to correctly reply to a tweet. Note: user laziness is *not* a failure on the part of the user, this is a failure on the part of Twitter. Requiring a user to go through a specific part of the UI just to reply to a tweet is not acceptable. When is a viable compromise solution going to get implemented so that @replies become tolerable again?
[twitter-dev] Re: in reply to metadata missing for manual replies
Most of them are coming either from Twitterrific or from web, but that's probably just an artifact of those users whom I follow. Most of my friends on Twitter are those who do Mac and iPhone development, and are most likely using Twitterrific on their Macs. Incidentally, it was pointed out to me that m.twitter.com does not even offer the reply swooshes that set the in reply to metadata. So much for Twitter clients conforming to the new API. :rolleyes: Also, it should be noted that while there are some users that are constant violators (and seemingly never go through the UI steps to set up the in reply to metadata), other users sometimes *simply forget* to make a tweet so the correct metadata is applied. This is expected; humans make errors all the time. Breaking metadata because of it is lame. -- Simone On 3 Mar, 16:07, Chad Etzel jazzyc...@gmail.com wrote: Just curious, of these replies that *should* be linked to a specific tweet, how many are coming from web and how many from another application ? -Chad
[twitter-dev] Re: in reply to metadata missing for manual replies
Uh, Twitter doesn't *need* to read users' minds, it just needs to merge the two approaches together. Before, Twitter auto-linked everything, and manual replies were considered genuine replies even if they weren't. Now, it auto-links nothing, and manual replies aren't auto-linked even if they *are* genuine replies. So Twitter can auto-link manual replies that aren't specifically marked as such (e.g.: by clicking the reply swoosh in the web interface), and store that data *separately* from genuine replies that are specifically marked as replies. That is, the in_reply_to data can have a flag letting the client know if the data was auto-linked or if it was not. Then, clients can decide what to do with that extra data. For example, there could be a setting in the Twitter web interface to show in reply to links for manual replies *and* genuine replies, or to show in reply to links only for genuine replies. That way it can satisfy me (and the other users that feel the same way), as well as those that only want the most accurate links between conversations. I (and some of my followers) think that more context is better than no context at all, even if the context is only approximate. Others think that only accurate context is valuable, and approximate context isn't at all. Such a change would preserve *more* metadata and would allow *both* kinds of users to use Twitter how they want to. -- Simone On 3 Mar, 16:24, atebits loren.brich...@gmail.com wrote: Requiring a user to go through a specific part of the UI just to reply to a tweet is not acceptable. How else would you expect it to work? Twitter can't read users' minds.
[twitter-dev] Re: in reply to metadata missing for manual replies
One of my main concerns is with SMS. There is current *no* way for SMS users to reply to a specific status. I recently submitted an issue to make the in_reply_to_status_id updatable so people could repair their broken threads if they wanted to. But it has been marked as wont fix. http://code.google.com/p/twitter-api/issues/detail?id=309 Are there more false positives happening before the change or are there more correct links that are now not being applied? I would wager the first is correct. I find it nice that now they are almost always correct. On Tue, Mar 3, 2009 at 19:04, simX simsimb...@gmail.com wrote: Uh, Twitter doesn't *need* to read users' minds, it just needs to merge the two approaches together. Before, Twitter auto-linked everything, and manual replies were considered genuine replies even if they weren't. Now, it auto-links nothing, and manual replies aren't auto-linked even if they *are* genuine replies. So Twitter can auto-link manual replies that aren't specifically marked as such (e.g.: by clicking the reply swoosh in the web interface), and store that data *separately* from genuine replies that are specifically marked as replies. That is, the in_reply_to data can have a flag letting the client know if the data was auto-linked or if it was not. Then, clients can decide what to do with that extra data. For example, there could be a setting in the Twitter web interface to show in reply to links for manual replies *and* genuine replies, or to show in reply to links only for genuine replies. That way it can satisfy me (and the other users that feel the same way), as well as those that only want the most accurate links between conversations. I (and some of my followers) think that more context is better than no context at all, even if the context is only approximate. Others think that only accurate context is valuable, and approximate context isn't at all. Such a change would preserve *more* metadata and would allow *both* kinds of users to use Twitter how they want to. -- Simone - Show quoted text - On 3 Mar, 16:24, atebits loren.brich...@gmail.com wrote: Requiring a user to go through a specific part of the UI just to reply to a tweet is not acceptable. How else would you expect it to work? Twitter can't read users' minds. -- Abraham Williams | http://the.hackerconundrum.com Web608 | Community Evangelist | http://web608.org This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: In Reply To
Added to the FAQ: http://apiwiki.twitter.com/FAQ#HowdoIgetallrepliestoaparticularstatus On Fri, Feb 20, 2009 at 22:36, Duane Storey duanesto...@gmail.com wrote: Is there any way to query all the replies to a particular status ID? I scanned the API but didn't see anything. Thanks. -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
