[twitter-dev] Re: Twitter buying Tweetie
+1 for Dewald getting his own session at Chirp! ;) (Seriously!) On Apr 10, 2:49 pm, Dewald Pretorius dpr...@gmail.com wrote: Maybe it's because I'm of the older generation, have been there and done that, and have discovered that the top looks so green because of all the crap that lies and flies there, that I hold the opinions that I do. I can understand folks' ambitions to make it. I guess in a way it's like a green recruit versus a veteran soldier. When you ask a green recruit about war, you will get answers about glorious deeds, killing the evil enemy, the honor of dying for your country, great adventure, and the like. When you ask a veteran soldier about war, you will get answers about rotting corpses, pieces of human meat splattered everywhere, being shit scared, losing your best buddies, and fighting and taking risks only to protect your buddies. Someone couldn't pay me enough to be at the top. The lifestyle is not worth the other sacrifices you need to make. On Apr 10, 6:25 pm, Dewald Pretorius dpr...@gmail.com wrote: Chad, Sometimes (well, okay, almost always) I just don't feel like citing all possible caveats to what I'm saying. I'm not writing here with visions of possible literary grandeur, potential book deals, or speaking engagements. I call shit like I see it. Sometimes I'm right, sometimes I'm wrong. It's just my opinion. Don't take what I say as gospel. Yes, there are ethical investors too. But, when the entrepeneur's ethics clash with the investor's ethics, or lack thereof, guess who is going to win. It does not require board level action or majority vote to put pressure on an entrepreneur. Simple verbal threats regarding current and future investments often suffice. On Apr 10, 6:13 pm, Chad Etzel jazzyc...@gmail.com wrote: On Sat, Apr 10, 2010 at 1:21 PM, Dewald Pretorius dpr...@gmail.com wrote: If you're an entrpreneur with strong ethical standards, then never ever accept investment capital. You cannot be serious. Believe it or not there are ethical investors out there. Also, bootstrapping a company that goes huge is almost impossible, especially for the younger entrepreneurial crowd that can afford the time and lifestyle that it would entail but probably does not have tons of cash in the bank. Can you please site such a company that received zero outside investment dollars? -Chad- Hide quoted text - - Show quoted text - -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Changing profile info, avoiding pending email is invalid errors
Many of our users are complaining that recently, using our app, they are getting bizarre Account update failed: pending email is invalid errors when trying to change profile info on Twitter (location, full name, bio). I see that this is a known issue -- http://bit.ly/bFs79q (not sure if there is a bug tracker for this one?), and am wondering a) when a fix is planned and b) if there are any ways to avoid this problem? It is happening for a subset of our users, not all users... so what's the scoop? It happens if the user has changed emails in the past? Or if we are using basic vs oauth? Or what? To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: Application Suspended
Presumably to do the OAuth vanity plate, you have to do what you described in your disgruntled developer post above. I.e., the user registers their own OAuth app and enters the corresponding values in your app, allowing you to masquerade as their app in tweets. Frankly, it seems to run counter to the purposes of OAuth. But the developer of one vanity plate app I found publishes email correspondence with Brian from Twitter, and says they have been personally vetted by Twitter, so I guess it is okay... On Feb 16, 7:58 am, Dewald Pretorius dpr...@gmail.com wrote: I see what you mean. It will be great to know what is the Twitter approved way of providing vanity plates. It is obviously a feature that will rock, if we can get a level playing field by that rule being made public to all of us. On Feb 16, 11:04 am, PJB pjbmancun...@gmail.com wrote: Vanity plate OAuth is already pretty rampant. And apparently acceptable by Twitter, too? That's at least what the leading Desktop purveyor of such a system says... something along the lines of officially authorized by Twitter.
[twitter-dev] Re: Application Suspended
Thanks very much for the reply... On Feb 16, 10:46 am, Ryan Sarver rsar...@twitter.com wrote: Sorry I am a little late to the thread and there are a lot of topics here so I'll do my best to cover them. 1. Email notices - we send out an email for warnings and for suspensions every time to the email on record for the account that is being suspended. If the email isn't up to date or isn't valid then you won't receive it, but otherwise an email goes out every time. So it would be good to make sure the email on record for each account is a valid one. 2. Dispute a warning or suspension - we've always said that emailing a...@twitter.com is the right path for disputing a warning or suspension. If you feel that you have emailed us at that address and haven't gotten a response, let me know, but the whole reason we use ticketing on that email endpoint is to make sure we follow up with each thread. 3. Publication of policies - we are working to make them clearer and easier to find. However, we disagree that posting explicit boundaries is a good idea. The policies are in place to help enforce the spirit of Twitter which cannot be broken down into explicit numbers. If you are having problems with living on the edges of the unpublished numbers, then you are likely doing something that is not within the spirit of the platform. 4. Hostile language - we have said over and over that we are open to constructive criticism. It forces us to be better and we strive to be better, however, we won't put up with hostile and inflammatory language on the list. We're all professionals here and we expect a certain level of professionalism from everyone on the list. Let me know if you have any questions. Best, Ryan On Tue, Feb 16, 2010 at 8:59 AM, Dewald Pretorius dpr...@gmail.com wrote: Nom nom nom, say the spammers. Add to that method a few proxies and/or IP addresses, or something as simple as giving your users a PHP proxy pass-thru script that they can upload to their servers, and there is no way that Twitter can even identify the offending app, let alone suspend/ban/blackhole it. On Feb 16, 12:28 pm, PJB pjbmancun...@gmail.com wrote: Presumably to do the OAuth vanity plate, you have to do what you described in your disgruntled developer post above. I.e., the user registers their own OAuth app and enters the corresponding values in your app, allowing you to masquerade as their app in tweets. Frankly, it seems to run counter to the purposes of OAuth. But the developer of one vanity plate app I found publishes email correspondence with Brian from Twitter, and says they have been personally vetted by Twitter, so I guess it is okay...
[twitter-dev] Re: Application Suspended
Might I suggest that since you now have email contact with Twitter, that you cease copying ALL of your correspondence with them to this group? On Feb 16, 1:53 pm, Jim Fulford j...@fulford.me wrote: Brian, I have made the requested changes to my application, but the support ticket has been closed and is no longer available. Who do I contac to request to have my application turned back on? I hope it won't take as long to check on this as it did for my first notice :) Also, I cannot get to oauth_client section of my twitter_account, so I have no facility to test anything or see when and if the applciation has been made active again. Thanks Jim
[twitter-dev] Re: Application Suspended
Wow. What's really of concern is the capricious approach Twitter seems to have with app developers. Some apps are given a month to make a change, some are cut off immediately, some are sent legal letters, some are contacted beforehand, some aren't. Frankly, there should be no tracking code. If there is an issue, apart from extreme situations, Twitter should contact the app and, as they apparently did with socialtoo, give some reasonable period of time to remedy. On Feb 15, 10:02 am, Peter Denton petermden...@gmail.com wrote: Twitter should at least send a notification suspension, as well as a tracking code possibly, for both parties benefits, twitter and the app. *Reason*: My app was suspended, for something perfectly harmless, and was re-granted permission the next day, but it took a few communications with twitter to resolve. This is only going to continue to become more and more frequent. I would hate to envision a team of a few people having to follow up on app suspensions w/o reference. On Mon, Feb 15, 2010 at 6:15 AM, Dewald Pretorius dpr...@gmail.com wrote: The argument of, Clearly defining rules helps the spammers because then they know exactly how to stay just within the boundaries, holds _absolutely no_ water. Imagine you own an ice rink. You draw a circle with a radius of 2 meters on the ice, and make the rule that it's okay to skate inside the circle, and not okay to skate outside the circle. If someone skates right at the edge, at 1.999 meters, all the time, it _does not matter_ because you have decided that it is okay and acceptable to skate there. The same goes with Twitter rules. Make the rules very granular and very clear. Then, if someone skates just within the fringes, _it does not matter_ because they are still within what you deem acceptable. And, then _everyone_ knows where is the line between good and bad application behavior, because then it is a fence and not a broad gray smudge. Most app developers are _not_ the enemy and most app developers will be more than happy to not develop or to disable features that violate the rules. If only we can understand the rules. On Feb 15, 12:04 am, PJB pjbmancun...@gmail.com wrote: +1 to what Dewald says. We are purposely NOT developing certain features for fear that Twitter may suddenly change their rules once again. Is this the sort of business environment that Twitter wishes to foster? We had assumed that, at the very least, applications would be contacted before any sort of action on Twitter's behalf. But apparently not. And apparently this push for OAuth integration is simply a means to more easily cut-off access to certain apps. Ugly. On Feb 14, 4:30 pm, Dewald Pretorius dpr...@gmail.com wrote: I attempted to make clear that my issue was not with the guilt or innocence of GoTwitr. It's with the message being sent to all of us when no communication accompanies a suspension. I'm going to beat the dead horse yet again. With vague and nebulous rules, nobody knows for certain what is allowed and what is not. Twitter invite people to build businesses using their system and API. By providing the platform, extending the invitation, and making the rules, they are also assuming a responsibility. It is a grave concern that one's business can be terminated by Twitter with no warning and no explanation, based on some rule that nobody knows for certain exactly what it entails. It would have been a slightly different situation had their rules been as clearly defined as Facebook's rules, but they're not, with intention. Take follower churn for example. Do I churn followers if I unfollow ten people in a day, and follow five others? Or do I only churn if I unfollow a hundred? Or is it two hundred? Or, wait, is the number immaterial while my intention puts me in violation or not? If so, how is my intention discerned? Take duplicate content for example. If I tweet Happy New Year! every January 1st, is that duplicate content? What about Good morning tweeps! every morning? Will my personal and business accounts be suspended if I tweet, Can't wait for the iPad! from the same IP address at roughly the same time? What if I did what Guy Kawasaki recommended athttp://bit.ly/jkSA1andtweetedthe same text four times a day, will my account be suspended? These are question my users ask me, and I don't have an answer for them. On Feb 14, 6:51 pm, Tim Haines tmhai...@gmail.com wrote: Dewald, Try looking in the google cache. I'm surprised it was allowed to live for as long as it did. http://74.125.155.132/search?q=cache:o2N2KuZsuYgJ:www.gotwitr.com/+go... It was basically a spam enabler. T. On Mon, Feb 15, 2010 at 11:27 AM, Dewald Pretorius dpr...@gmail.com wrote: I cannot comment on what Jim's site did
[twitter-dev] Re: Application Suspended
I thought Twitter didn't like bots? If so, why did they apparently have one send out suspension warnings? That's at least my conclusion given their non-response to questions, at least in that case. (As well, it seems as though the OAuth push is, at least in part, about app policing.) One would have thought that the Twitter police would be better aimed at enacting policies to deal with abuse by end-users, rather than such a heavy hand against apps. What's next? TweetDeck is going to be banned because they allow single-button duplicate tweets across multiple accounts? Some of us have built businesses and livelihoods around Twitter. It's scary to have those things threatened by the possibility of capricious enforcement handled by no questions please email demands. On Feb 15, 11:11 am, Abraham Williams 4bra...@gmail.com wrote: Sounds like Twitter dropped the ball with notifications. It appears that Twitter normally does send notifications before suspension as Refollow [1] got 2 warning. Although Rob had the issue of no response to clarifications. Abraham [1]http://refollow.tumblr.com/post/380619972/weve-been-suspended-by-twitter On Mon, Feb 15, 2010 at 10:34, PJB pjbmancun...@gmail.com wrote: Wow. What's really of concern is the capricious approach Twitter seems to have with app developers. Some apps are given a month to make a change, some are cut off immediately, some are sent legal letters, some are contacted beforehand, some aren't. Frankly, there should be no tracking code. If there is an issue, apart from extreme situations, Twitter should contact the app and, as they apparently did with socialtoo, give some reasonable period of time to remedy. On Feb 15, 10:02 am, Peter Denton petermden...@gmail.com wrote: Twitter should at least send a notification suspension, as well as a tracking code possibly, for both parties benefits, twitter and the app. *Reason*: My app was suspended, for something perfectly harmless, and was re-granted permission the next day, but it took a few communications with twitter to resolve. This is only going to continue to become more and more frequent. I would hate to envision a team of a few people having to follow up on app suspensions w/o reference. On Mon, Feb 15, 2010 at 6:15 AM, Dewald Pretorius dpr...@gmail.com wrote: The argument of, Clearly defining rules helps the spammers because then they know exactly how to stay just within the boundaries, holds _absolutely no_ water. Imagine you own an ice rink. You draw a circle with a radius of 2 meters on the ice, and make the rule that it's okay to skate inside the circle, and not okay to skate outside the circle. If someone skates right at the edge, at 1.999 meters, all the time, it _does not matter_ because you have decided that it is okay and acceptable to skate there. The same goes with Twitter rules. Make the rules very granular and very clear. Then, if someone skates just within the fringes, _it does not matter_ because they are still within what you deem acceptable. And, then _everyone_ knows where is the line between good and bad application behavior, because then it is a fence and not a broad gray smudge. Most app developers are _not_ the enemy and most app developers will be more than happy to not develop or to disable features that violate the rules. If only we can understand the rules. On Feb 15, 12:04 am, PJB pjbmancun...@gmail.com wrote: +1 to what Dewald says. We are purposely NOT developing certain features for fear that Twitter may suddenly change their rules once again. Is this the sort of business environment that Twitter wishes to foster? We had assumed that, at the very least, applications would be contacted before any sort of action on Twitter's behalf. But apparently not. And apparently this push for OAuth integration is simply a means to more easily cut-off access to certain apps. Ugly. On Feb 14, 4:30 pm, Dewald Pretorius dpr...@gmail.com wrote: I attempted to make clear that my issue was not with the guilt or innocence of GoTwitr. It's with the message being sent to all of us when no communication accompanies a suspension. I'm going to beat the dead horse yet again. With vague and nebulous rules, nobody knows for certain what is allowed and what is not. Twitter invite people to build businesses using their system and API. By providing the platform, extending the invitation, and making the rules, they are also assuming a responsibility. It is a grave concern that one's business can be terminated by Twitter with no warning and no explanation, based on some rule that nobody knows for certain exactly what it entails. It would have been a slightly different situation had their rules been as clearly
[twitter-dev] Re: Application Suspended
Frankly, I sort of hope that Twitter DOESN'T further define their nebulous rules. Why? Because when they do, the axe often falls on legitimate app developers (rather than abusive users or problem apps) in really short-sighted ways. Moreover, their rules are usually blanket pronouncements without regard for important business cases for certain features. For example, Twitter used to say that follower churn was against their rules. Okay, that's certainly fair and fine. But now they've recently changed their rules page (in mid-November, to be exact) to outright ban ALL automated following, except -- bizarrely -- follow- back. This is really silly. It kills an entire functionality space for all apps simply because some uses of it are abusive. For example, auto-follow is a hallmark feature of Google Buzz. It was loudly included in all press mentions of this product. Namely, in that app, you auto-follow anyone you frequently email with. (Google has apparently curtailed this feature due to privacy concerns.) So what about a similar Twitter app that offers this perfectly reasonable feature -- namely, auto-follow anyone that you @tweet more than, say, 10 times. Will that be banned? Apparently. (And there goes the whole CRM market with it!) Or what about an app that unfollows anyone who tweets spam or swear words? Nope, such an app is apparently outlawed. Twitter should err on the side of allowing developers the freedom to build great apps. This should mean hand-holding even the smallest app (not just the biggies). But, more than that, it should mean offering flexibility and good faith when it comes to deciding what's an appropriate use of the Twitter API. Blanket, mid-stream, and developer-focused restrictions are non-constructive, unfair, and will stifle innovation. Many of us support our families with Twitter development; and it is cavalier and bruising to know that developers are apparently not offered at least some level of back-and-forth communication, good faith, and case-by-case leeway when their apps are examined in relation to Twitter rules. On Feb 15, 3:36 pm, Dewald Pretorius dpr...@gmail.com wrote: I apologize for my choice of words. Now, can we get back to discussing Twitter using OAuth as a mechanism to heavy-handedly suspend applications as witnessed by the two recent cases we know of, while measuring the guilt of the application against nebulous rules that nobody knows exactly what they mean? Please. On Feb 15, 7:17 pm, Cameron Kaiser spec...@floodgap.com wrote: Oh for crying out loud, is everyone now going to stare themselves blind at the phrase Gestapo-like and forget about the issue at hand? It is meant to portray a one-sided action where the accused party is not afforded a voice, or his/her objections, rationale, or explanations are ignored. Then say that instead of throwing bombs. Don't tell me you used the term in order to provoke absolutely *no* reaction at all. -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com*ckai...@floodgap.com -- This manual has been carefully for errors to make sure correct. -- classiccmp
[twitter-dev] Re: Application Suspended
Yep, that should have been implicit in my post. Anti-spam actions should be chiefly aimed at abusive users, rather than developers. After all, it may be pretty easy for Twitter to limit what Web-based apps can do, but won't such behavior just shift to the Desktop, in even more flagrant and ridiculous flavors? And won't legitimate business uses be unfairly taken out (or never get off the ground) in such developer dragnets? Sadly, it seems as though a chief impetus behind the OAuth push is for exactly that reason: to more tightly regulate and limit third-party Twitter apps. On Feb 15, 5:24 pm, Dewald Pretorius dpr...@gmail.com wrote: Well PJB, there is always a completely different approach that Twitter could take. They could bolster their internal coding and defenses against what they consider to be abuse, much like they did for duplicate content, and then not suspend applications at all. That way applications can try whatever they want. If they run into a Twitter defense, such as a rejected update, then no harm is done on either side, except maybe wasted bandwidth and processing resources. On Feb 15, 9:16 pm, PJB pjbmancun...@gmail.com wrote: Frankly, I sort of hope that Twitter DOESN'T further define their nebulous rules. Why? Because when they do, the axe often falls on legitimate app developers (rather than abusive users or problem apps) in really short-sighted ways. Moreover, their rules are usually blanket pronouncements without regard for important business cases for certain features. For example, Twitter used to say that follower churn was against their rules. Okay, that's certainly fair and fine. But now they've recently changed their rules page (in mid-November, to be exact) to outright ban ALL automated following, except -- bizarrely -- follow- back. This is really silly. It kills an entire functionality space for all apps simply because some uses of it are abusive. For example, auto-follow is a hallmark feature of Google Buzz. It was loudly included in all press mentions of this product. Namely, in that app, you auto-follow anyone you frequently email with. (Google has apparently curtailed this feature due to privacy concerns.) So what about a similar Twitter app that offers this perfectly reasonable feature -- namely, auto-follow anyone that you @tweet more than, say, 10 times. Will that be banned? Apparently. (And there goes the whole CRM market with it!) Or what about an app that unfollows anyone who tweets spam or swear words? Nope, such an app is apparently outlawed. Twitter should err on the side of allowing developers the freedom to build great apps. This should mean hand-holding even the smallest app (not just the biggies). But, more than that, it should mean offering flexibility and good faith when it comes to deciding what's an appropriate use of the Twitter API. Blanket, mid-stream, and developer-focused restrictions are non-constructive, unfair, and will stifle innovation. Many of us support our families with Twitter development; and it is cavalier and bruising to know that developers are apparently not offered at least some level of back-and-forth communication, good faith, and case-by-case leeway when their apps are examined in relation to Twitter rules. On Feb 15, 3:36 pm, Dewald Pretorius dpr...@gmail.com wrote: I apologize for my choice of words. Now, can we get back to discussing Twitter using OAuth as a mechanism to heavy-handedly suspend applications as witnessed by the two recent cases we know of, while measuring the guilt of the application against nebulous rules that nobody knows exactly what they mean? Please. On Feb 15, 7:17 pm, Cameron Kaiser spec...@floodgap.com wrote: Oh for crying out loud, is everyone now going to stare themselves blind at the phrase Gestapo-like and forget about the issue at hand? It is meant to portray a one-sided action where the accused party is not afforded a voice, or his/her objections, rationale, or explanations are ignored. Then say that instead of throwing bombs. Don't tell me you used the term in order to provoke absolutely *no* reaction at all. -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com*ckai...@floodgap.com -- This manual has been carefully for errors to make sure correct. -- classiccmp
[twitter-dev] Re: Application Suspended
+1 to what Dewald says. We are purposely NOT developing certain features for fear that Twitter may suddenly change their rules once again. Is this the sort of business environment that Twitter wishes to foster? We had assumed that, at the very least, applications would be contacted before any sort of action on Twitter's behalf. But apparently not. And apparently this push for OAuth integration is simply a means to more easily cut-off access to certain apps. Ugly. On Feb 14, 4:30 pm, Dewald Pretorius dpr...@gmail.com wrote: I attempted to make clear that my issue was not with the guilt or innocence of GoTwitr. It's with the message being sent to all of us when no communication accompanies a suspension. I'm going to beat the dead horse yet again. With vague and nebulous rules, nobody knows for certain what is allowed and what is not. Twitter invite people to build businesses using their system and API. By providing the platform, extending the invitation, and making the rules, they are also assuming a responsibility. It is a grave concern that one's business can be terminated by Twitter with no warning and no explanation, based on some rule that nobody knows for certain exactly what it entails. It would have been a slightly different situation had their rules been as clearly defined as Facebook's rules, but they're not, with intention. Take follower churn for example. Do I churn followers if I unfollow ten people in a day, and follow five others? Or do I only churn if I unfollow a hundred? Or is it two hundred? Or, wait, is the number immaterial while my intention puts me in violation or not? If so, how is my intention discerned? Take duplicate content for example. If I tweet Happy New Year! every January 1st, is that duplicate content? What about Good morning tweeps! every morning? Will my personal and business accounts be suspended if I tweet, Can't wait for the iPad! from the same IP address at roughly the same time? What if I did what Guy Kawasaki recommended athttp://bit.ly/jkSA1and tweeted the same text four times a day, will my account be suspended? These are question my users ask me, and I don't have an answer for them. On Feb 14, 6:51 pm, Tim Haines tmhai...@gmail.com wrote: Dewald, Try looking in the google cache. I'm surprised it was allowed to live for as long as it did.http://74.125.155.132/search?q=cache:o2N2KuZsuYgJ:www.gotwitr.com/+go... It was basically a spam enabler. T. On Mon, Feb 15, 2010 at 11:27 AM, Dewald Pretorius dpr...@gmail.com wrote: I cannot comment on what Jim's site did or didn't do, since he has pulled all descriptive information from the site. Nevertheless, it is highly disturbing that applications are being suspended without any notice. This particular site seems to have had a contact form, plus it was OAuth, so the owner could have been contacted via the email address on file for the Twitter user that owns the application. Yes, some apps do stuff that warrant suspension. But, to just suspend an app with no communication is bad. If Twitter don't want to give some sites the opportunity to correct transgressive behavior (I know they do communicate in some cases), at the very least send an email to the owner with, Your service has been suspended because..., and give a clear path and instructions on how the situation can be remedied as soon as possible. I'm going to say it again, Twitter: Your rules are vague and nebulous. Not everyone understands and interprets the rules the way you do internally. You must realize that actions like these sometimes shout so loud that we cannot hear when you say, We care about our developers. Rightly or wrongly, here's a developer who has lost face with his user base, and has been in the dark for 4 days now. The message it sends to us, the other developers, is a very bad message. If you properly communicated with Jim, he probably wouldn't even have posted about it here. On Feb 14, 3:56 pm, Jim Fulford j...@fulford.me wrote: Hello, I need some help. 4 days ago I started getting emails from my users that they could not login to our site using the Oauth service. I checked my site and it said my application had been suspended. I did not get any email from Twitter, they just deactivated my application so nothing works. I have sent in two support tickets, but gotten no response. 2 days ago, I took my site downwww.gotwitr.com so that I would stop getting support email from my users. I have had this site up for 5 months, and I have over 5000 users have used the service. I am so glad that I have never charged for the service, this would be a nightmare. If they would let me know what our site, or one of our users did to get banned, we would be glad to fix it. We have tried to make our site as Twitter API friendly as possible. We are 100%
[twitter-dev] non-ASCII Twitter screen names
Just FYI, Twitter screen names are not (or, apparently, didn't use to be) restricted to 0-9A-Z-_ id6295462/id screen_nameMagic carpet1/screen_name id3939231/id screen_nameWalking the dog2/screen_name id92595586/id screen_nameIts mine\nM2/screen_name We're also seeing non-ASCII in some other screen names. (Though we don't currently know what they are... we just know they exist! ;) We're assuming this is a vestige of long ago coding? It does screw up our desire to use ascii char(15) in db... Maybe Twitter can fix?
[twitter-dev] Re: non-ASCII Twitter screen names
Hm, wait... this account was created in Nov 2009 and has spaces and a \n in his screen_name?? http://twitter.com/users/show.xml?user_id=92595586 On Feb 3, 4:59 pm, PJB pjbmancun...@gmail.com wrote: Just FYI, Twitter screen names are not (or, apparently, didn't use to be) restricted to 0-9A-Z-_ id6295462/id screen_nameMagic carpet1/screen_name id3939231/id screen_nameWalking the dog2/screen_name id92595586/id screen_nameIts mine\nM2/screen_name We're also seeing non-ASCII in some other screen names. (Though we don't currently know what they are... we just know they exist! ;) We're assuming this is a vestige of long ago coding? It does screw up our desire to use ascii char(15) in db... Maybe Twitter can fix?
[twitter-dev] Re: non-ASCII Twitter screen names
I'm speculating, but I wonder if you do a blind form post to change usernames with non-ascii characters whether it will accept them? I think part of the validation by Twitter is done client-side (or so it appears), and that the Twitter databases store screen_name in utf-8 rather than ascii. I searched my database and found a number of Twitter screen names with spaces. But we have been getting a number of warnings about non-ascii characters... no idea what these are yet (as our database won't hold them as we (wrongly) assumed that they would only be ascii). But I am warn'ing them out and will report what I find. It would be rather crazy to find, say, a single character Chinese Twitter screen name! On Feb 3, 5:49 pm, Abraham Williams 4bra...@gmail.com wrote: Huh. I wonder if they can still sign in... You can also see one of them on the web herehttp://twitter.com/account/redirect_by_id?id=92595586 Other then an account here and there, from what was probably a bug in the validation code, there should be no accounts being created with such characters. crosses fingers Abraham On Wed, Feb 3, 2010 at 17:03, PJB pjbmancun...@gmail.com wrote: Hm, wait... this account was created in Nov 2009 and has spaces and a \n in his screen_name?? http://twitter.com/users/show.xml?user_id=92595586 On Feb 3, 4:59 pm, PJB pjbmancun...@gmail.com wrote: Just FYI, Twitter screen names are not (or, apparently, didn't use to be) restricted to 0-9A-Z-_ id6295462/id screen_nameMagic carpet1/screen_name id3939231/id screen_nameWalking the dog2/screen_name id92595586/id screen_nameIts mine\nM2/screen_name We're also seeing non-ASCII in some other screen names. (Though we don't currently know what they are... we just know they exist! ;) We're assuming this is a vestige of long ago coding? It does screw up our desire to use ascii char(15) in db... Maybe Twitter can fix? -- Abraham Williams | Community Advocate |http://abrah.am Project | Out Loud |http://outloud.labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States
[twitter-dev] Hey, Twitter, let us buy sidebar ads! (Or, stop focusing on the biggies.)
Right now, the ad in the sidebar on the right-hand side of Twitter.com is invariably: i) a micro, community, or feel-good sort of app, ii) a mega-app that most people already know about, that has VC, connections to Twitter folks directly, or a good PR firm. This leaves many non-Bay Area (or medium-sized) apps out in the cold. So... can Twitter stop anointing the top dogs in such a willy-nilly fashion? Instead of this annoyingly vague editor's choice language about the selections, can you either set-up a transparent process whereby apps can be submitted, voted on, whatever... or just convert the whole thing to paid ads? It's incredibly frustrating to see sub-par apps like wefollow.com promoted just because its founder is buddy-buddy with Twitter folks. Or for other well-known apps get their version 2 promoted just because, well, it's version 2 and it's well-known. The choices you guys make have significant repercussions. And it's increasingly frustrating to find you guys focusing more and more on market leaders. While I suppose that may make sense from your perspective, it deprives smaller apps of their ability to compete, and it ultimately stifles competition. It would be far easier if we were allowed SOME VOICE by converting the whole thing to paid ads, and letting us buy at least SOME space. (Or why not just list ALL apps, and weight their presence by, e.g., click-thrus, votes, etc.)
[twitter-dev] API speed is kicking ass lately...
Woo hoo... something must have changed... for at least the past 24 hours, I am noticing incredible performance from API calls. Seems to be at least 40% faster than earlier in the week.
[twitter-dev] Re: API speed is kicking ass lately...
Your question is not germane to the topic at hand. Nor, for that matter, is it germane to this discussion group at all. On Jan 15, 12:21 am, BrandonUSA brandon...@gmail.com wrote: Is there a service to remove all the people you are following at once?
[twitter-dev] Re: Social Graph API: Legacy data format will be eliminated 1/11/2010
Can we please get some confirmation that the cursor-less calls won't
be going away this coming Monday?
On Dec 22 2009, 4:13 pm, Wilhelm Bierbaum wilh...@twitter.com wrote:
We noticed that some clients are still calling social graph methods
without cursor parameters. We wanted to take time to make sure that
people were calling the updated methods which return data with cursors
instead of the old formats that do not.
As previously announced in September (http://bit.ly/46x1iL) and
November (http://bit.ly/3UQ0LU), the legacy data formats returned
as a result of calling social graph endpoints without a cursor
parameter are deprecated and will be removed.
These formats have been removed from the API wiki since September.
You should always pass a cursor parameter. Starting soon, if you fail
to pass a cursor, the data returned will be that of the first cursor
(-1) and the next_cursor and previous_cursor elements will be included.
If you aren't seeing next_cursor and previous_cursor in your results,
you are getting data back in the old format. You will need to adjust
your parser to handle the new format.
We're going to start assuming you want data in the new format
(users_list / users / user or id_list / ids / id) instead of the old
format (users / user or ids / id) regardless of your passing a cursor
parameter as of 1/11/2010.
* The old formats will no longer be returned after 1/11/2010.
* Start using the new formats now by passing the 'cursor' parameter.
To recap, the old endpoints at
/statuses/friends.xml
/statuses/followers.xml
returned
users type=array
user
!-- ... omitted ... --
/user
/users
or JSON like [{/*user record*/ /*, .../]
whereas
/statuses/friends.xml?cursor=n
/statuses/followers.xml?cursor=n
return data that looks like
users_list
users type=array
user
!-- ... omitted ... --
/user
/users
next_cursor7128872798413429387/next_cursor
previous_cursor0/previous_cursor
/users_list
or, the JSON equivalent:
{users:[{/*user record*/} /*, ...*/], next_cursor:0,
previous_cursor:0}
and the old endpoints at
/friends/ids.xml
/followers/ids.xml
returned data that looks like
ids
id1/id
id2/id
id3/id
/ids
whereas
/friends/ids.xml?cursor=n
/followers/ids.xml?cursor=n
return data that looks like
id_list
ids
id1/id
id2/id
id3/id
/ids
next_cursor1288724293877798413/next_cursor
previous_cursor-1300794057949944903/previous_cursor
/id_list
or, the JSON equivalent:
{ids:[1, 2, 3], next_cursor:0, previous_cursor:0}
If you have any questions or comments, please feel free to post them
to twitter-development-talk.
Thanks!
--
Wilhelm Bierbaum
Twitter Platform Team
[twitter-dev] Re: Social Graph API: Legacy data format will be eliminated 1/11/2010
I think that's like asking someone: why do you eat food? But don't say because it tastes good or nourishes you, because we already know that! ;) You guys presumably set the 5000 ids per cursor limit by analyzing your user base and noting that one could still obtain the social graph for the vast majority of users with a single call. But this is a bit misleading. For analytics-based apps, who aim to do near real-time analysis of relationships, the focus is typically on consumer brands who have a far larger than average number of relationships (e.g., 50k - 200k). This means that those apps are neck-deep in cursor-based stuff, and quickly realize the existing drawbacks, including, in order of significance: - Latency. Fetching ids for a user with 3000 friends is comparable between the two calls. But as you increment past 5000, the speed quickly peaks at a 5+x difference (I will include more benchmarks in a short while). For example, fetching 80,000 friends via the get-all method takes on average 3 seconds; it takes, on average, 15 seconds with cursors. - Code complexity elegance. I would say that there is a 3x increase in code lines to account for cursors, from retrying failed cursors, to caching to account for cursor slowness, to UI changes to coddle impatient users. - Incomprehensibility. While there are obviously very good reasons from Twitter's perspective (performance) to the cursor based model, there really is no apparent obvious benefit to API users for the ids calls. I would make the case that a large majority of API uses of the ids calls need and require the entire social graph, not an incomplete one. After all, we need to know what new relationships exist, but also what old relationships have failed. To dole out the data in drips and drabs is like serving a pint of beer in sippy cups. That is to say: most users need the entire social graph, so what is the use case, from an API user's perspective, of NOT maintaining at least one means to quickly, reliably, and efficiently get it in a single call? - API Barriers to entry. Most of the aforementioned arguments are obviously from an API user's perspective, but there's something, too, for Twitter to consider. Namely, by increasing the complexity and learning curve of particular API actions, you presumably further limit the pool of developers who will engage with that API. That's probably a bad thing. - Limits Twitter 2.0 app development. This, again, speaks to issues bearing on speed and complexity, but I think it is important. The first few apps in any given media or innovation invariably have to do with basic functionality building blocks -- tweeting, following, showing tweets. But the next wave almost always has to do with measurement and analysis. By making such analysis more difficult, you forestall the critically important ability for brands, and others, to measure performance. - API users have requested it. Shouldn't, ultimately, the use case for a particular API method simply be the fact that a number of API developers have requested that it remain? On Jan 4, 2:07 pm, Wilhelm Bierbaum wilh...@twitter.com wrote: Can everyone contribute their use case for this API method? I'm trying to fully understand the deficiencies of the cursor approach. Please don't include that cursors are slow or that they are charged against the rate limit, as those are known issues. Thanks.
[twitter-dev] Re: Social Graph API: Legacy data format will be eliminated 1/11/2010
Some quick benchmarks... Grabbed entire social graph for ~250 users, where each user has a number of friends/followers between 0 and 80,000. I randomly used both the cursor and cursor-less API methods. 5000 ids cursor: 0.72 avg seconds cursorless: 0.51 avg seconds 5000 to 10,000 ids cursor: 1.42 avg seconds cursorless: 0.94 avg seconds 1 to 80,000 ids cursor: 2.82 avg seconds cursorless: 1.21 avg seconds 5,000 to 80,000 ids cursor: 4.28 cursorless: 1.59 10,000 to 80,000 ids cursor: 5.23 cursorless: 1.82 20,000 to 80,000 ids cursor: 6.82 cursorless: 2 40,000 to 80,000 ids cursor: 9.5 cursorless: 3 60,000 to 80,000 ids cursor: 12.25 cursorless: 3.12 On Jan 4, 7:58 pm, Jesse Stay jesses...@gmail.com wrote: Ditto PJB :-) On Mon, Jan 4, 2010 at 8:12 PM, PJB pjbmancun...@gmail.com wrote: I think that's like asking someone: why do you eat food? But don't say because it tastes good or nourishes you, because we already know that! ;) You guys presumably set the 5000 ids per cursor limit by analyzing your user base and noting that one could still obtain the social graph for the vast majority of users with a single call. But this is a bit misleading. For analytics-based apps, who aim to do near real-time analysis of relationships, the focus is typically on consumer brands who have a far larger than average number of relationships (e.g., 50k - 200k). This means that those apps are neck-deep in cursor-based stuff, and quickly realize the existing drawbacks, including, in order of significance: - Latency. Fetching ids for a user with 3000 friends is comparable between the two calls. But as you increment past 5000, the speed quickly peaks at a 5+x difference (I will include more benchmarks in a short while). For example, fetching 80,000 friends via the get-all method takes on average 3 seconds; it takes, on average, 15 seconds with cursors. - Code complexity elegance. I would say that there is a 3x increase in code lines to account for cursors, from retrying failed cursors, to caching to account for cursor slowness, to UI changes to coddle impatient users. - Incomprehensibility. While there are obviously very good reasons from Twitter's perspective (performance) to the cursor based model, there really is no apparent obvious benefit to API users for the ids calls. I would make the case that a large majority of API uses of the ids calls need and require the entire social graph, not an incomplete one. After all, we need to know what new relationships exist, but also what old relationships have failed. To dole out the data in drips and drabs is like serving a pint of beer in sippy cups. That is to say: most users need the entire social graph, so what is the use case, from an API user's perspective, of NOT maintaining at least one means to quickly, reliably, and efficiently get it in a single call? - API Barriers to entry. Most of the aforementioned arguments are obviously from an API user's perspective, but there's something, too, for Twitter to consider. Namely, by increasing the complexity and learning curve of particular API actions, you presumably further limit the pool of developers who will engage with that API. That's probably a bad thing. - Limits Twitter 2.0 app development. This, again, speaks to issues bearing on speed and complexity, but I think it is important. The first few apps in any given media or innovation invariably have to do with basic functionality building blocks -- tweeting, following, showing tweets. But the next wave almost always has to do with measurement and analysis. By making such analysis more difficult, you forestall the critically important ability for brands, and others, to measure performance. - API users have requested it. Shouldn't, ultimately, the use case for a particular API method simply be the fact that a number of API developers have requested that it remain? On Jan 4, 2:07 pm, Wilhelm Bierbaum wilh...@twitter.com wrote: Can everyone contribute their use case for this API method? I'm trying to fully understand the deficiencies of the cursor approach. Please don't include that cursors are slow or that they are charged against the rate limit, as those are known issues. Thanks.
[twitter-dev] Re: Social Graph API: Legacy data format will be eliminated 1/11/2010
On Jan 4, 8:58 pm, John Kalucki j...@twitter.com wrote: at the moment). So, it seems that we're returning the data over home DSL at between 2,500 and 4,000 ids per second, which seems like a perfectly reasonable rate and variance. It's certainly not reasonable to expect it to take 10+ seconds to get 25,000 to 40,000 ids, PARTICULARLY when existing methods, for whatever reason, return the same data in less than 2 seconds. Twitter is being incredibly short-sighted if they think this is indeed reasonable. Some of us have built applications around your EXISTING APIs, and to now suggest that we may need formal business relationships to continue to use such APIs is seriously disquieting. Disgusted...
[twitter-dev] Re: Social Graph API: Legacy data format will be eliminated 1/11/2010
As noted in this thread, the fact that cursor-less methods for friends/ followers ids will be deprecated was newly announced on December 22. In fact, the API documentation still clearly indicates that cursors are optional, and that their absence will return a complete social graph. E.g.: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-followers%C2%A0ids (If the cursor parameter is not provided, all IDs are attempted to be returned) The example at the bottom of that page gives a good example of retrieving 300,000+ ids in several seconds: http://twitter.com/followers/ids.xml?screen_name=dougw Of course, retrieving 20-40k users is significantly faster. Again, many of us have built apps around cursor-less API calls. To now deprecate them, with just a few days warning over the holidays, is clearly inappropriate and uncalled for. Similarly, to announce that we must now expect 5x slowness when doing the same calls, when these existing methods work well, is shocking. Many developers live and die by the API documentation. It's a really fouled-up situation when the API documentation is so totally wrong, right? I urge those folks addressing this issue to preserve the cursor-less methods. Barring that, I urge them to return at least 25,000 ids per cursor (as you note, time progression has made 5000 per call antiquated and ineffective for today's Twitter user) and grant at least 3 months before deprecation. On Jan 4, 10:23 pm, John Kalucki j...@twitter.com wrote: The existing APIs stopped providing accurate data about a year ago and degraded substantially over a period of just a few months. Now the only data store for social graph data requires cursors to access complete sets. Pagination is just not possible with the same latency at this scale without an order of magnitude or two increase in cost. So, instead of hardware units in the tens and hundreds, think about the same in the thousands and tens of thousands. These APIs and their now decommissioned backing stores were developed when having 20,000 followers was a lot. We're an order of magnitude or two beyond that point along nearly every dimension. Accounts. Followers per account. Tweets per second. Etc. As systems evolve, some evolutionary paths become extinct. Given boundless resources, the best we could do for a REST API, as Marcel has alluded, is to do the cursoring for you and aggregate many blocks into much larger responses. This wouldn't work very well for at least two immediate reasons: 1) Running a system with multimodal service times is a nightmare -- we'd have to provision a specific endpoint for such a resource. 2) Ruby GC chokes on lots of objects. We'd have to consider implementing this resource in another stack, or do a lot of tuning. All this to build the opposite of what most applications want: a real-time stream of graph deltas for a set of accounts, or the list of recent set operations since the last poll -- and rarely, if ever, the entire following set. Also, I'm a little rusty on the details on the social graph api, but please detail which public resources allow retrieval of 40,000 followers in two seconds. I'd be very interested in looking at the implementing code on our end. A curl timing would be nice (time curl URL /dev/null) too. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Mon, Jan 4, 2010 at 9:18 PM, PJB pjbmancun...@gmail.com wrote: On Jan 4, 8:58 pm, John Kalucki j...@twitter.com wrote: at the moment). So, it seems that we're returning the data over home DSL at between 2,500 and 4,000 ids per second, which seems like a perfectly reasonable rate and variance. It's certainly not reasonable to expect it to take 10+ seconds to get 25,000 to 40,000 ids, PARTICULARLY when existing methods, for whatever reason, return the same data in less than 2 seconds. Twitter is being incredibly short-sighted if they think this is indeed reasonable. Some of us have built applications around your EXISTING APIs, and to now suggest that we may need formal business relationships to continue to use such APIs is seriously disquieting. Disgusted...
[twitter-dev] Re: Social Graph API: Legacy data format will be eliminated 1/11/2010
~300,000 ids in 15 seconds: $ time curl http://twitter.com/followers/ids.xml?screen_name=dougw / dev/null % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total Spent Left Speed 100 5545k 100 5545k0 0 346k 0 0:00:15 0:00:15 --:--:-- 474k real0m15.994s user0m0.021s sys 0m0.061s === ~100,000 ids in 6 seconds: $ time curl http://twitter.com/followers/ids.xml?screen_name=karlrove /dev/null % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total Spent Left Speed 100 1700k 100 1700k0 0 286k 0 0:00:05 0:00:05 --:--:-- 433k real0m5.932s user0m0.010s sys 0m0.025s === 12,000 ids in 1.2 seconds: $ time curl http://twitter.com/followers/ids.xml?screen_name=markos / dev/null % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total Spent Left Speed 100 213k 100 213k0 0 168k 0 0:00:01 0:00:01 --:--:-- 257k real0m1.269s user0m0.004s sys 0m0.003s === These calls are night-and-day better than cursor-based calls. Again, I plead with those folks pushing the bits about to preserve what is officially documented. On Jan 4, 10:23 pm, John Kalucki j...@twitter.com wrote: The existing APIs stopped providing accurate data about a year ago and degraded substantially over a period of just a few months. Now the only data store for social graph data requires cursors to access complete sets. Pagination is just not possible with the same latency at this scale without an order of magnitude or two increase in cost. So, instead of hardware units in the tens and hundreds, think about the same in the thousands and tens of thousands. These APIs and their now decommissioned backing stores were developed when having 20,000 followers was a lot. We're an order of magnitude or two beyond that point along nearly every dimension. Accounts. Followers per account. Tweets per second. Etc. As systems evolve, some evolutionary paths become extinct. Given boundless resources, the best we could do for a REST API, as Marcel has alluded, is to do the cursoring for you and aggregate many blocks into much larger responses. This wouldn't work very well for at least two immediate reasons: 1) Running a system with multimodal service times is a nightmare -- we'd have to provision a specific endpoint for such a resource. 2) Ruby GC chokes on lots of objects. We'd have to consider implementing this resource in another stack, or do a lot of tuning. All this to build the opposite of what most applications want: a real-time stream of graph deltas for a set of accounts, or the list of recent set operations since the last poll -- and rarely, if ever, the entire following set. Also, I'm a little rusty on the details on the social graph api, but please detail which public resources allow retrieval of 40,000 followers in two seconds. I'd be very interested in looking at the implementing code on our end. A curl timing would be nice (time curl URL /dev/null) too. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Mon, Jan 4, 2010 at 9:18 PM, PJB pjbmancun...@gmail.com wrote: On Jan 4, 8:58 pm, John Kalucki j...@twitter.com wrote: at the moment). So, it seems that we're returning the data over home DSL at between 2,500 and 4,000 ids per second, which seems like a perfectly reasonable rate and variance. It's certainly not reasonable to expect it to take 10+ seconds to get 25,000 to 40,000 ids, PARTICULARLY when existing methods, for whatever reason, return the same data in less than 2 seconds. Twitter is being incredibly short-sighted if they think this is indeed reasonable. Some of us have built applications around your EXISTING APIs, and to now suggest that we may need formal business relationships to continue to use such APIs is seriously disquieting. Disgusted...
[twitter-dev] Re: Social Graph API: Legacy data format will be eliminated 1/11/2010
Willhelm:
Your announcement is apparently expanding the changeover from page to
cursor in new, unannounced ways??
The API documentation page says: If the cursor parameter is not
provided, all IDs are attempted to be returned, but large sets of IDs
will likely fail with timeout errors.
Yesterday you wrote: Starting soon, if you fail to pass a cursor, the
data returned will be that of the first cursor (-1) and the
next_cursor and previous_cursor elements will be included.
I can understand the need to swap from page to cursor, but was pleased
that a single call was still available to return (or attempt to
return) all friend/follower ids. Now you are saying that, in addition
to the changeover from page to cursor, you are also getting rid of
this?
Can you please confirm/deny?
On Dec 22, 4:13 pm, Wilhelm Bierbaum wilh...@twitter.com wrote:
We noticed that some clients are still calling social graph methods
without cursor parameters. We wanted to take time to make sure that
people were calling the updated methods which return data with cursors
instead of the old formats that do not.
As previously announced in September (http://bit.ly/46x1iL) and
November (http://bit.ly/3UQ0LU), the legacy data formats returned
as a result of calling social graph endpoints without a cursor
parameter are deprecated and will be removed.
These formats have been removed from the API wiki since September.
You should always pass a cursor parameter. Starting soon, if you fail
to pass a cursor, the data returned will be that of the first cursor
(-1) and the next_cursor and previous_cursor elements will be included.
If you aren't seeing next_cursor and previous_cursor in your results,
you are getting data back in the old format. You will need to adjust
your parser to handle the new format.
We're going to start assuming you want data in the new format
(users_list / users / user or id_list / ids / id) instead of the old
format (users / user or ids / id) regardless of your passing a cursor
parameter as of 1/11/2010.
* The old formats will no longer be returned after 1/11/2010.
* Start using the new formats now by passing the 'cursor' parameter.
To recap, the old endpoints at
/statuses/friends.xml
/statuses/followers.xml
returned
users type=array
user
!-- ... omitted ... --
/user
/users
or JSON like [{/*user record*/ /*, .../]
whereas
/statuses/friends.xml?cursor=n
/statuses/followers.xml?cursor=n
return data that looks like
users_list
users type=array
user
!-- ... omitted ... --
/user
/users
next_cursor7128872798413429387/next_cursor
previous_cursor0/previous_cursor
/users_list
or, the JSON equivalent:
{users:[{/*user record*/} /*, ...*/], next_cursor:0,
previous_cursor:0}
and the old endpoints at
/friends/ids.xml
/followers/ids.xml
returned data that looks like
ids
id1/id
id2/id
id3/id
/ids
whereas
/friends/ids.xml?cursor=n
/followers/ids.xml?cursor=n
return data that looks like
id_list
ids
id1/id
id2/id
id3/id
/ids
next_cursor1288724293877798413/next_cursor
previous_cursor-1300794057949944903/previous_cursor
/id_list
or, the JSON equivalent:
{ids:[1, 2, 3], next_cursor:0, previous_cursor:0}
If you have any questions or comments, please feel free to post them
to twitter-development-talk.
Thanks!
--
Wilhelm Bierbaum
Twitter Platform Team
[twitter-dev] Re: Social Graph API: Legacy data format will be eliminated 1/11/2010
API documentation page says: If the cursor parameter is not provided, all IDs are attempted to be returned, but large sets of IDs will likely fail with timeout errors. There was no reference in any of the previous announcements to deprecating this valuable ability. Is it now also doomed for the ash- heap, and we shall never get more than 5000 ids at a time with these calls? That was never indicated to be the case in the prior announcements, nor does the API documentation page hint at this new change...?!
[twitter-dev] Re: Social Graph API: Legacy data format will be eliminated 1/11/2010
Why hasn't this been announced before? Why does the API suggest
something totally different? At the very least, can you please hold
off on deprecation of this until 2/11/2010? This is a new API change.
On Dec 23, 7:45 pm, Raffi Krikorian ra...@twitter.com wrote:
yes - if you do not pass in cursors, then the API will behave as though you
requested the first cursor.
Willhelm:
Your announcement is apparently expanding the changeover from page to
cursor in new, unannounced ways??
The API documentation page says: If the cursor parameter is not
provided, all IDs are attempted to be returned, but large sets of IDs
will likely fail with timeout errors.
Yesterday you wrote: Starting soon, if you fail to pass a cursor, the
data returned will be that of the first cursor (-1) and the
next_cursor and previous_cursor elements will be included.
I can understand the need to swap from page to cursor, but was pleased
that a single call was still available to return (or attempt to
return) all friend/follower ids. Now you are saying that, in addition
to the changeover from page to cursor, you are also getting rid of
this?
Can you please confirm/deny?
On Dec 22, 4:13 pm, Wilhelm Bierbaum wilh...@twitter.com wrote:
We noticed that some clients are still calling social graph methods
without cursor parameters. We wanted to take time to make sure that
people were calling the updated methods which return data with cursors
instead of the old formats that do not.
As previously announced in September (http://bit.ly/46x1iL) and
November (http://bit.ly/3UQ0LU), the legacy data formats returned
as a result of calling social graph endpoints without a cursor
parameter are deprecated and will be removed.
These formats have been removed from the API wiki since September.
You should always pass a cursor parameter. Starting soon, if you fail
to pass a cursor, the data returned will be that of the first cursor
(-1) and the next_cursor and previous_cursor elements will be included.
If you aren't seeing next_cursor and previous_cursor in your results,
you are getting data back in the old format. You will need to adjust
your parser to handle the new format.
We're going to start assuming you want data in the new format
(users_list / users / user or id_list / ids / id) instead of the old
format (users / user or ids / id) regardless of your passing a cursor
parameter as of 1/11/2010.
* The old formats will no longer be returned after 1/11/2010.
* Start using the new formats now by passing the 'cursor' parameter.
To recap, the old endpoints at
/statuses/friends.xml
/statuses/followers.xml
returned
users type=array
user
!-- ... omitted ... --
/user
/users
or JSON like [{/*user record*/ /*, .../]
whereas
/statuses/friends.xml?cursor=n
/statuses/followers.xml?cursor=n
return data that looks like
users_list
users type=array
user
!-- ... omitted ... --
/user
/users
next_cursor7128872798413429387/next_cursor
previous_cursor0/previous_cursor
/users_list
or, the JSON equivalent:
{users:[{/*user record*/} /*, ...*/], next_cursor:0,
previous_cursor:0}
and the old endpoints at
/friends/ids.xml
/followers/ids.xml
returned data that looks like
ids
id1/id
id2/id
id3/id
/ids
whereas
/friends/ids.xml?cursor=n
/followers/ids.xml?cursor=n
return data that looks like
id_list
ids
id1/id
id2/id
id3/id
/ids
next_cursor1288724293877798413/next_cursor
previous_cursor-1300794057949944903/previous_cursor
/id_list
or, the JSON equivalent:
{ids:[1, 2, 3], next_cursor:0, previous_cursor:0}
If you have any questions or comments, please feel free to post them
to twitter-development-talk.
Thanks!
--
Wilhelm Bierbaum
Twitter Platform Team
--
Raffi Krikorian
Twitter Platform Teamhttp://twitter.com/raffi
[twitter-dev] Re: Perl OAuth - updated example
On Oct 21, 11:28 pm, Nigel Cannings nigelcanni...@googlemail.com wrote: Hope that is a better explanation, and might I say on behalf of all the Perl hackers on the list, keep the good work up! Hear hear! Net::Twitter is a brilliant and easy-to-use Perl interface to Twitter.
[twitter-dev] Re: API Performance Tanking
From my testing, SOME api calls go through just fine (e.g., grabbing DMs). OTHERS are particularly slow (e.g., create friend). From the rumours I have heard, Twitter is delegating performance to more benign calls, and degrading performance for other calls more closely associated with spam activities. I hope this is not true. On Oct 21, 8:01 pm, Dewald Pretorius dpr...@gmail.com wrote: On Wednesday afternoon/evening the 502s and connection refuses have been coming thick and fast, much worse than earlier in the week. When can we expect to see an improvement instead of a worsening of the API's performance? Dewald
[twitter-dev] Re: API Performance Tanking
I should add that that rumour is probably pure speculation. But it does strike me as odd that some calls work perfectly fine, while others are significantly delayed. Possibly the degradation is due to the deals Twitter struck today with Google and Microsoft's Bing? Presumably these behemoths are eating up significant API resources. On Oct 21, 9:54 pm, PJB pjbmancun...@gmail.com wrote: From my testing, SOME api calls go through just fine (e.g., grabbing DMs). OTHERS are particularly slow (e.g., create friend). From the rumours I have heard, Twitter is delegating performance to more benign calls, and degrading performance for other calls more closely associated with spam activities. I hope this is not true. On Oct 21, 8:01 pm, Dewald Pretorius dpr...@gmail.com wrote: On Wednesday afternoon/evening the 502s and connection refuses have been coming thick and fast, much worse than earlier in the week. When can we expect to see an improvement instead of a worsening of the API's performance? Dewald
[twitter-dev] Re: Duplicate Tweets
What kept me up at night is wondering what is coming down the pike... who knows if feature X, Y, or Z in your new Twitter app might get a stop-work order from Twitter. That's really scary. On Oct 14, 11:13 am, Neicole neic...@trustneicole.com wrote: Is Twitter crazy?! Have they even looked at their own user, market, and competitor information? Twitter has said they are actively pursuing businesses (and bloggers) and doing away with recurring tweets does away with key business value. Besides, there are technical solutions to this problem, so why implement a blanket policy that will negatively impact Twitter and its users. I just blogged my reasons, based on data, for why this is such a BAD idea. Dear Twitter, please don't kill your markethttp://bit.ly/1N5AHA On Oct 13, 1:31 pm, JDG ghil...@gmail.com wrote: Yes, and should be treated as such. I personally detest all those stupid twitter-based games. Point is, with Twitter's userbase, some get through the cracks. Don't like it, report it. This is like complaining that cops only pull over SOME speeders. Yeah, some are going to get through the cracks. On Tue, Oct 13, 2009 at 14:29, PJB pjbmancun...@gmail.com wrote: For the sake of argument, let's take this at face value as true. How about the search pollution issue with recurrent tweets in general? You may have a point. But it comes down to uneven enforcement. Twitter smacks down an app because they allow an individual to recur, say, every Monday: Today is Monday and my office hours will be from 2:15-3:30pm. Meanwhile, you have apps which do things like this: http://search.twitter.com/search?q=%23fun140 Aren't those effectively recurring tweets? -- Internets. Serious business.- Hide quoted text - - Show quoted text -
[twitter-dev] Re: Duplicate Tweets
Twitter is being incredibly stupid, rash, and short-sighted about this. Does ATT write to Microsoft and say, hey, our network is getting a lot of junk email sent through Microsoft Outlook. We therefore demand you get rid of the CC and BCC features of that product. Of course not! That Twitter is now focusing on regulating Twitter APPS shows that it has a weak and ineffective user regulation system in place. It can't effectively police its users, so it decides to go after apps that they (may) use. Cheap shot. It's like stopping drunk driving by banning all driving after dark. Do they really think that that is going to work? Sure, they can probably slam down Web-based clients that use dedicated, whitelisted IP addresses. But as I pointed out earlier, this will just shift the behavior, and make it even more nettlesome. Now it will move to desktop clients that they cannot stop (yes, they can still ban individual members for duplicate content, but they cannot stop the sale and use of the desktop client). Months ago I emailed Twitter asking them what OUR responsibilities were as app developers. I think all of us understand and recognize that many of our apps have features that could be abused. I think many of us are perfectly willing to police our own apps, and work with Twitter to help reign in behavior that isn't acceptable. But it seems out-of-bounds for Twitter to bypass such a cooperative system, and instead just carte blanche ban a particular app feature that has many legitimate uses. On Oct 13, 6:32 am, JDG ghil...@gmail.com wrote: They can still check for duplicate tweets, and can still suspend accounts violating the TOS, regardless of client. On Mon, Oct 12, 2009 at 23:23, PJB pjbmancun...@gmail.com wrote: I worried about this. Doesn't Twitter realize this will just shift things to desktop apps which they have less control over?!? On Oct 12, 7:24 pm, Dewald Pretorius dpr...@gmail.com wrote: Any developer who has included and/or is thinking about including a recurring tweet feature in your app, please take note that they are against Twitter TOS. You can read what Twitter wrote to me here: http://www.socialoomphblog.com/recurring-tweets/ -- Internets. Serious business.
[twitter-dev] Re: basic help needed on connect to TWITTER and send a tweet with PERL
http://search.cpan.org/dist/Net-Twitter/lib/Net/Twitter.pod
On Oct 13, 3:33 am, apfelmaennchen alexander.grefr...@gmail.com
wrote:
I really find it difficult to understand documentation how to code a
TWITTER-API in perl. But with a bit start-help, I think I'll be able
to proceed.
Can somebody help me with a sample PERL-code:
From within a PERL script ( which has two variables filled with
strings. names of those VARS are $VAR1, $VAR2) I want to
a) connect to twitter (lets assume username = test, password =
water)
b) send a tweet Hello world $VAR1 {space} $VAR2. This is my first
test tweet automatically posted from a perl script.
c) disconnect from twitter
Maybe you also can give a command-reference, something like perl
TWITTER API in a nutshell.
Very many thanks for your help, Alex
[twitter-dev] Re: Duplicate Tweets
If the desktop client uses OAuth (which, if and when they deprecate basic auth, will be all), you bet your ass they can regulate desktop clients. All they have to do is ban any tweets using the Consumer Secret and Key for that app (and any subsequent keys said jackass developer attempts to get after previous tokens have been banned). Wrong. Basic Authentication will obviously ALWAYS be an option for desktop clients, regardless of whether or not it is via API. Furthermore, the app in question explicitly offered the option of a recurring tweet which is a violation of the TOS. Regardless of whether or not that provides a useful service -- I'm not going to start debating that -- the fact of the matter is it *is* a violation of the TOS. Plain and simple. Why shouldn't they be allowed (as if we have a say what a private company does with their own resources) to ban an app that violates the TOS with one of their own options? I see, so then sites like mapmyrun and others that, for example, tweet Bob ran 10 miles today in 2 hours, Bob ran 12 miles today in 1 hour, and other templated text, are also in violation of the terms? Or what about hootsuite where I can queue up 100 tweets with the exact same text to fire off every hour, perhaps interspersed with a second tweet? The bottom line is that this situation isn't as black and white as you think, and Twitter's approach is wrong-headed.
[twitter-dev] Re: Duplicate Tweets
On Oct 13, 12:48 pm, JDG ghil...@gmail.com wrote: Wrong. Basic Authentication will obviously ALWAYS be an option for desktop clients, regardless of whether or not it is via API. Explain to me where it's obvious that basic auth will ALWAYS be an option for desktop clients. Furthermore, please explain to me what voodoo you employed while reading those statements to come to your conclusion. You clearly do not understand the basics of HTTP. Do you think that Twitter is going to somehow deny Firefox, IE, and other desktop clients from connecting to Twitter with a simple username and password only? I see, so then sites like mapmyrun and others that, for example, tweet Bob ran 10 miles today in 2 hours, Bob ran 12 miles today in 1 hour, and other templated text, are also in violation of the terms? Or what about hootsuite where I can queue up 100 tweets with the exact same text to fire off every hour, perhaps interspersed with a second tweet? Why on earth would people do that? Why on earth would you want to tweet the exact same text once an hour for 100 consecutive hours. What benefit could that POSSIBLY provide to the Twitter ecosystem? I am beginning to realize it is of no use arguing with you. Obviously there is no benefit. That's the point: that both the app in question AND those apps provide means for violating Twitter's Terms of Service.
[twitter-dev] Re: Duplicate Tweets
You clearly do not understand the basics of HTTP. Do you think that Twitter is going to somehow deny Firefox, IE, and other desktop clients from connecting to Twitter with a simple username and password only? Since when do Firefox and IE use the API to communicate with Twitter? Last time I checked, they don't...but maybe I am just missing something. My point is that desktop apps can perform Twitter actions without going through the API. Any crackdown on particular behaviors of Web-based Twitter apps will likely see that behavior shift to desktop apps, as they are exceedingly difficult, if not impossible, to centrally restrict.
[twitter-dev] Re: Duplicate Tweets
For the sake of argument, let's take this at face value as true. How about the search pollution issue with recurrent tweets in general? You may have a point. But it comes down to uneven enforcement. Twitter smacks down an app because they allow an individual to recur, say, every Monday: Today is Monday and my office hours will be from 2:15-3:30pm. Meanwhile, you have apps which do things like this: http://search.twitter.com/search?q=%23fun140 Aren't those effectively recurring tweets?
[twitter-dev] Re: Duplicate Tweets
Chad: Sorry, I didn't see you had posted in here, and not sure if my subsequent posts properly answered you. I mean that Desktop apps, not being bound by a whitelisted IP, wouldn't be limited by restrictions limiting API access to OAUTH only. Namely, a desktop client could use a Mozilla user-agent, scrape Twitter.com, grab an authenticity_token, and then do a simple HTTP form submission with plaintext username/password. From there, the client could do whatever outlawed actions aren't possible from Web apps. While you could presumably find some commonalities with these logins for a time, probably the only effective way to counter this approach is to introduce login captchas. And that's an ugly barrier to entry for the average user. Restricting Web-based apps will presumably shift the policed behavior to such desktop apps, where it would probably morph into something even more destructive. As a web-based developer, I've previously asked for guidelines on what our responsibilities are in terms of self-policing. No answer. And it's really disheartening to hear that carte blanche limitations are now being imposed. There are obvious legitimate uses for recurring dynamic tweets (e.g., NBC announcing show schedules/guests, or fitness apps tweeting how many miles you ran). Blocking such behavior across the board seems incredibly short-sighted and limits further important business- oriented development in this area. PB On Oct 13, 12:47 pm, Chad Etzel c...@twitter.com wrote: On Tue, Oct 13, 2009 at 3:38 PM, PJB pjbmancun...@gmail.com wrote: Wrong. Basic Authentication will obviously ALWAYS be an option for desktop clients, regardless of whether or not it is via API. Please explain this statement? -Chad Furthermore, the app in question explicitly offered the option of a recurring tweet which is a violation of the TOS. Regardless of whether or not that provides a useful service -- I'm not going to start debating that -- the fact of the matter is it *is* a violation of the TOS. Plain and simple. Why shouldn't they be allowed (as if we have a say what a private company does with their own resources) to ban an app that violates the TOS with one of their own options? I see, so then sites like mapmyrun and others that, for example, tweet Bob ran 10 miles today in 2 hours, Bob ran 12 miles today in 1 hour, and other templated text, are also in violation of the terms? Or what about hootsuite where I can queue up 100 tweets with the exact same text to fire off every hour, perhaps interspersed with a second tweet? The bottom line is that this situation isn't as black and white as you think, and Twitter's approach is wrong-headed.
[twitter-dev] Re: Duplicate Tweets
I worried about this. Doesn't Twitter realize this will just shift things to desktop apps which they have less control over?!? On Oct 12, 7:24 pm, Dewald Pretorius dpr...@gmail.com wrote: Any developer who has included and/or is thinking about including a recurring tweet feature in your app, please take note that they are against Twitter TOS. You can read what Twitter wrote to me here: http://www.socialoomphblog.com/recurring-tweets/
[twitter-dev] Re: Twitter API in 24 Hours
What are you going to do when Twitter makes a huge unannounced change to their API in, say, 3 months and totally alters everything? It has happened before; it will happen again! This isn't a particularly mature platform to be writing about, especially with a publication date 6+ months away! On Oct 9, 2:42 pm, Andrew Mager andrew.ma...@gmail.com wrote: I am co-authoring a book about the Twitter API, and I was wondering if any of you guys wanted to write a chapter. The book will be in the SAMS 24 hour series, and it's scheduled to be released mid-next year. Here is our tentative table of contents: Introduction to Twitter An overview of Twitter and Microblogging Common Types of Twitter Applications Key Issues to Consider when Developing Twitter Apps Overview of Twitters's API structure The API is HTTP-based The API uses Representational State Transfer (REST) There are pagination limits The Twitter API supports UTF-8 encoding Getting Started with the API Setting up an environment Making your first API call Parsing the reply Message, date, author, image Creating a simple display Setting up an application framework Creating a twitter Class Various twitter libraries are available PHP Class used in this book Modifing our class Twitter Error messages What each error code means Modifing our twitter Class Passing credentials to twitter Standard method (HTTP) Using cookies (create, retrieve, delete) OAuth Sending and Receiving messages from Twitter Creating a basic twitter client Sending messages in twitter Twitter search Dealing with Twitter downtimes and errors Twitter Beyond the API Future of Twitter Example Applications Other Mashup Twitter Services Twitter Etiquette Ping me directly if you are interested! andrew.ma...@gmail.com
[twitter-dev] Re: twitter.com/followers/befriend_all ?
If it is not in the Twitter API documentation, if the API call not work for you, if you see no reference to it here on this forum... I am at a loss why you are asking whether it exists or not. Clearly it does not. On Oct 7, 11:29 am, Rick Yazwinski rick.yazwin...@gmail.com wrote: I see comments via google about having a bot call this regularily to make sure your bot follows anyone following the bot... makes sense (rather than getting all friends and all followers and issuing seperate friend requests), however I see no reference to it on the twitter api site. Is this legit? When I call it it just redirects to my home page. Rick...
[twitter-dev] Re: Account management app - suspended accounts
Agreed. What else is wefollow.com, which Twitter freely advertises, but a ranking of people by followers (just look at some of the top people in the categories and you have to ask yourself, wtf!?) When the value of a Twitter account is determined by followers (as apps like wefollow make clear), then people will obviously and naturally try to increase their follower counts. I mean, Twitter freely advertises twittercounter.com too... and that app even shows charted daily growth in followers, prompting viewers to wonder how they, too, can have such growth. And, personally, I don't necessarily see anything wrong with that. After all, which is more detrimental to the community, someone like Karl Rove or Rick Sanchez or Arnold Schwarzenegger using some auto- follow technique, or the 10s of 1000s of BS accounts tweeting about weight loss or promotional URL @replies to random people? I wish Twitter would focus it's anti-spam tactics MORE on the content of the tweet stream, rather than on some amorphous following abuse which they undercut by highlighting apps like wefollow. Or at least a combination of the two. There's too many accounts tweeting about weight loss, etc... and it's a shame when folks like Karl Rove, Rick Sanchez, and others get suspended because they apparently fell afoul of follow/unfollow. A quick look at their tweet stream and it is apparent they are not spammers. There's too many false positives in the current anti-spam dragnets, and far too little focus on the clear-as-day spam tweets currently making Twitter increasingly hard to use. On Oct 9, 12:59 pm, Dewald Pretorius dpr...@gmail.com wrote: One more thought about this. Audience (followers) is to Twitter what PageRank is to Google. Twitter created a commodity when it enabled the unlimited follower capability. As long as it is a commodity, money-motivated people will continue to exploit it as a commodity, just like they exploit Google's PageRank. The entire SEO industry is centered around ranking high in SE's, with Google's PageRank being one of the most coveted commodities. You can expect to see an entire industry forming around gaining Twitter followers. And very clever people will continuously try to outsmart you to circumvent any counter-measures that you try to implement. The only way to win that battle is to make followers a non-commodity. Dewald On Oct 9, 4:04 pm, Dewald Pretorius dpr...@gmail.com wrote: John, With reference to used for invalid purposes in your post. That begs the question, what exactly constitute invalid purposes? From a Twitter purist's point of view, anything other than What are you doing? constitutes an invalid purpose. I'd venture to say that very few people use Twitter for What are you doing? No way do I want to or need to tell a few thousand strangers (and have it indexed by Google) where I am right now, what I am doing right now, or what I am having for lunch. Facebook is a far better platform for that, where one has privacy and a hand-picked audience who just might care. Twitter created a platform that is ideally suited for the marketers and mega-phones. Why else would people actually spend money to buy followers, and get involved in all kinds of schemes to acquire more followers? Because the way your platform works enables and encourages that type of purpose. When you find yourself spending many frustrating hours of fighting invalid use, you are in effect fighting the animal that Twitter created. One cannot be angry with users when they use the service in unforeseen ways, especially when the service enables that type of use. The easiest way to fight invalid use is to change Twitter so that only valid use is possible. When Facebook realized that they were enabling the mega-phone type, they quickly changed their system to discourage that use by limiting the number of friends one can have. You either have to do that, or you have to expand your definition of valid use, and rejoice in the success it brings you when people use your service in unexpected and unanticipated ways. By having a flexible platform that encourages many purposes and trying to limit those purposes only to what you deem valid, you are forever going to fight a losing battle. And, you are laying down rich soil for the competition to germinate. If every who does not stick to What are you doing? abandoned Twitter today, you will be back to where you were in your early days in terms of size and relevance. Dewald On Oct 9, 2:07 pm, John Kalucki jkalu...@gmail.com wrote: Openness about abuse is generally counter-productive for everyone. For example, opaque limits are harder to game and give better detection signals. Also, practically, limits need to be adjusted without notice to respond changing attacks. In the end, valid access that is difficult to distinguish from access overwhelmingly used for invalid purposes
[twitter-dev] Re: Account management app - suspended accounts
Well, in the last dragnet, http://twitter.com/ricksanchezcnn, http://twitter.com/scottkwalker, http://twitter.com/karlrove were all suspended. And while you might disagree with their politics, it's pretty evident from their tweets that they were not spammers. These well-known personalities (and several others) were quickly restored, but you have to wonder how many non-wellknown, non-spam accounts are now in the weeds waiting for Twitter to restore their accounts. Too many false positives, and too many unknown rules arbitrarily applied. On Oct 9, 12:05 pm, Andrew Badera and...@badera.us wrote: As someone who's been a Twitter user since March 2007 or so, and a developer since late 2007, I have a hard time disagreeing with anything I've seen from Twitter on spam policies. In general, it seems to me, if you're not a douchebag, you don't get suspended. With one or two exceptions in that entire time. ∞ Andy Badera ∞ +1 518-641-1280 ∞ This email is: [ ] bloggable [x] ask first [ ] private ∞ Google me:http://www.google.com/search?q=andrew%20badera On Fri, Oct 9, 2009 at 2:54 PM, freefall tehgame...@googlemail.com wrote: Yes exactly - Twitter doesnt live by a coherent ruleset. It openly promotes bots yet suspends people without any warning or information. It opens its doors to be gamed and kicks people out randomly. This lack of transparant rules is working like a charm isnt it. On Oct 9, 7:44 pm, Cameron Kaiser spec...@floodgap.com wrote: Openness about abuse is generally counter-productive for everyone. For example, opaque limits are harder to game and give better detection signals. Also, practically, limits need to be adjusted without notice to respond changing attacks. In the end, valid access that is difficult to distinguish from access overwhelmingly used for invalid purposes are sometimes, sadly, going to get caught in a low-latency high-volume countermeasure system. How about you just answer my question? What you're saying is mankind is wrong to live by well defined and concrete rules. Um, no. What John is saying is that Twitter doesn't live by them. And, considering that Twitter is a relatively new medium, that's pretty much by definition. Of course the reality is Twitter is another laissez fair bums on seats driven site and as google proved, there is nothing like the abiltiy to change the rules on a whim, or hide a problem for a company of this ilk. The line for Jaiku starts over there. -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com*ckai...@floodgap.com -- Prediction is very difficult, especially ... about the future. -- Niels Bohr
[twitter-dev] Re: Private user's 'following' information: why am I denied access via API but can get through Twitter.com?
This is an annoying inconsistency with the Twitter API. If you do an authenticated call to view a user's friends/followers, and that user is either blocking the authenticated user or is private, you will not be able to view their friends/followers. You will get not authorized error. However, if on Twitter.com, you login and try to do the same thing, you CAN do this. The solution in the API is to make UNauthenticated calls and you will be able to view friends/followers without issue. On Sep 3, 12:37 am, Tweet Thief tweetth...@gmail.com wrote: Summary Question: If a user is 'private' on Twitter, why can I see their followers on Twitter.com (IFF I log in) but not through the API? Details: For example, I went tohttp://twitter.com/just_me_hi/followers/and can see all of her followers, despite the fact that she is private (Note: I can see them on twitter.com while logged in even when I am fairly certain that she blocked me before going private.) curl -D - -s -u user:pass http://twitter.com/friendships/exists.xml?user_a=just_me_hiuser_b=tw...; Results in: HTTP/1.1 403 Forbidden Status: 403 Forbidden (irrelevant headers edited) ?xml version=1.0 encoding=UTF-8? hash request/friendships/exists.xml?user_a=just_me_hiamp;user_b=tweetthief/request errorYou do not have permission to retrieve following status for both specified users./error /hash PLEASE NOTE: I tried the same API access from another account I am 99.% sure she did NOT block, and it still gives me this permission error so it does NOT appear to have anything to do with whether or not this account is blocked and everything to do with the fact that the account is marked private… I don't understand why the API gives me less access to information than the website. T.T. ps: @just_me_hi appears to have gone private after I (and others) called her out for plagiarism in violation of the Twitter TOS. You can see the chain of events here: http://tweetthief.tumblr.com/tagged/justmehi/chrono --http://tweetthief.tumblr.com Shining a light on users who plagiarize on Twitter
[twitter-dev] Re: Comments for the group and Twitter staff
Please also stop willy-nilly changing the error codes and error messages. Since your error messages are so often inaccurate, some of us have setup special rules to decipher what the errors actually are -- when you change the text or code, our rules break. For example, suspended users are/were getting rate limit warnings when trying to authenticate as them. Separately, a new not authorized message appears for both failed authentication errors as well as successfully authenticated users trying friends/ids on blocking users. Since the messages and codes are the same, it is hard to distinguish between these error types to tell the user what is going on. There are about a half-dozen of these ambiguities and bad errors that we've accounted for. (Don't get me started on 200: OK non- errors.) So, after much trial and error, we CAN figure out the actual underlying problem based on the action and message you send us. But when you suddenly change the error code, or message, it throws our rules into disarray. (Of course, it would be nice if the actual error messages you sent were themselves accurate, but for now we're just hoping you can CONSISTENTLY send us the same inaccurate errors.) On Sep 15, 12:29 pm, Alex Payne a...@twitter.com wrote: We're planning on doing just that: communicating more, monitoring the API via a third-party service from a variety of locales, and providing better documentation. We've got more developer support hires lined up, and more. Thanks for the list of what you'd like to see, and thanks for bearing with us. On Tue, Sep 15, 2009 at 12:13, zippy_monster alex.zep...@gmail.com wrote: On Sep 15, 11:04 am, Alex Payne a...@twitter.com wrote: Please understand that the denormalized lists are currently provided to developers on a best-effort basis. For the vast majority of Twitter applications, this data isn't necessary. A specialized class of applications need this data, and we're doing our best to provide it. As a developer, implementation details are mainly a recreational interest. My primary concern is the end result (does it work? or not?). Excuses and apologies are nice, but not a substitute for more explicit testing and communication. So far I've run into two disruptive changes: - Today, for a brief period, API queries were returning twice the number of responses they should have. Instead of showing the proper 6 DMs, I was getting 12 back. Oops. - Previously, the way POST + OAuth requests were being handled changed. The code I was using (MGTwitterEngine + various OAuth hacks) was sending GET arguments with every request (even POST). For a while this worked, but in the past few weeks this broke with no warning. Yeah, that was sloppy client-side code, but the documentation was silent on this, and certainly the error message (invalid/re-used nonce) was not terribly helpful as a proper nonce was being generated each time. Additionally, Internet rumblings about how OAuth was handled lend credence to the idea that the API just isn't terribly stable... both from the idea that you're pushing people to use what is officially considered an experimental API, and that it's being treated as an experimental API (OAuth specific outages for instance). Or, the current pagination problems. The threads I see here seem to all be started by API consumers. What's missing from the picture is an announcement from Twitter that some feature is broken. That smacks of really poor (well, non-existent) communication. So, yeah, after spending time tracking down the above problems, and reading general internet rumblings, my gut feeling is that the Twitter API simply isn't terribly stable. Specifically, I wonder how serious Twitter is about testing things in a non-production environment. If I had to propose a solution, it would be to keep a more explicit list (blog, regular group postings, whatever) of what changes... even if you think it's insignificant. When something breaks, no matter how small, a formal announcement would be great. If such a thing exists, I sure don't know about it. The API blog hasn't been updated since July. The third hit on Google for twitter api is a post to this group begging for documentation. The API changelog is out there, but it too seems like it's not consistently updated. -- Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x
[twitter-dev] Re: Comments for the group and Twitter staff
Would be good if Twitter.com used API to determine, e.g., DM count on right-side. Right now it is woefully wrong if we delete DMs via API. On Sep 15, 2:16 pm, Alex Payne a...@twitter.com wrote: The main twitter.com site already uses the API in some places. Our revised mobile site is built entirely on the API, and our Facebook application has been built off our API for some time. Dogfooding! We support it. On Tue, Sep 15, 2009 at 14:08, Jim Renkel james.ren...@gmail.com wrote: I emphatically second and support the idea of twitter.com having to use the API. We had similar quality problems at a place I formerly worked, and they were solved, completely, when such a policy was instituted. Yeah, it puts pressure on the API team and may inconvenience the UI team, or whatever you call them, but in the long run it will be worth it. Side effects that we saw were a simpler, cleaner, more consistent architecture for the whole system, and lower total costs to develop and maintain the system. Bite the bullet and do it now. The longer you wait, the more difficult and expensive it will be. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott Haneda Sent: Tuesday, September 15, 2009 15:55 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: Comments for the group and Twitter staff Probably too late for this, but perhaps moving forward, it could be done... Twitter.com should move to using their own API. The tools they use to power their own site should be the same tools we use and rely on. In all reality, this seems a simpler approach, rather than pushing out code for their stuff, and then essentially backporting that to an API, just work on making the API, and then integrate that into the twitter.com site. As far as I can tell, this would solve pretty much every problem the API has, as there can not be a case where twitter is down, but the API is up, or the API is down, and twitter is up. Twitter should be eating their own dog food :) -- Scott * If you contact me off list replace talklists@ with scott@ * -- Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x
[twitter-dev] empty data + no error returned from friends/ids
We are seeing random, intermittent empty result sets from friends/ids, called without page or cursor arguments. These empty results return without error, and frequently correct themselves when tried again. Is this a known issue? What is the status of this issue?
[twitter-dev] Re: Draft: Twitter Rules for API Use
Dean: Can you please stop posting about your individual TWITTER ACCOUNT issue on a Twitter developer forum? No app was blacklisted in your case -- rather your account was suspended. There's a big difference, and this particular forum topic is about API Rules, NOT about Twitter account rules. While I'm sure your situation sucks, you are confusing and conflating this very important topic -- API rules -- with something totally different (Twitter user rules). PB On Sep 11, 7:21 am, Dean Collins d...@cognation.net wrote: Yep, this we can blacklist an app for any other reason as we deem fit, stuff is fine but don't expect other 3rd party developers to play along. I've been trying to get an exact number of people you can delete from a following in 24 hours without risking your twitter account from the tech support team following the suspension of my @LiveNFLchat account, no one seems to know/be prepared to state a number. We're happy to play by the rules, just spell out what those rules clearly are. Regards, Dean Collins Live Chat Concepts Inc d...@livechatconcepts.com +1-212-203-4357 New York +61-2-9016-5642 (Sydney in-dial). +44-20-3129-6001 (London in-dial). -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Friday, September 11, 2009 8:43 AM To: Twitter Development Talk Subject: [twitter-dev] Re: Draft: Twitter Rules for API Use I guess the lawyers wrote this draft as an extension of the modified Twitter TOS. Alex, you will need to jump on this draft from a dizzy height and get all your Platform rules in there. Once the API Rules are published as The Rules you will have no grounds to blacklist an application for other than what is written in The Rules. Unless the rules also state that, we can blacklist an app for any other reason as we deem fit, which will fly like a lead balloon. If the rules are not clear and comprehensive, they will become a ball and chain around the ankles of the Platform team. Dewald
[twitter-dev] Re: Draft: Twitter Rules for API Use
I think you're assuming that correlation equals causation. You have no idea why you were suspended, and any hypothesis you, or others come up with, is simply conjecture. It could be because you hit follow limit repeatedly, because you removed too many people, because (looking at your Google cache) you have a large number of advertisements, because most of your tweets contain links, because too many people blocked you, because too many people reported you as spam, because you were a victim of a phishing attack, because you logged in from multiple different IPs, because you clicked on a phishing link, and on and on. It's highly unlikely that you're going to find the answer here, however. The best bet is to follow their reporting system and almost certainly someone will get in touch with you to explain. I do hope you give Twitter a little more breathing room before you contact the press!!! ;) Regards, PB On Sep 11, 10:46 am, Dean Collins d...@cognation.net wrote: -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of PJB Sent: Friday, September 11, 2009 12:49 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Draft: Twitter Rules for API Use Dean: Can you please stop posting about your individual TWITTER ACCOUNT issue on a Twitter developer forum? No app was blacklisted in your case -- rather your account was suspended. There's a big difference, and this particular forum topic is about API Rules, NOT about Twitter account rules. While I'm sure your situation sucks, you are confusing and conflating this very important topic -- API rules -- with something totally different (Twitter user rules). PB Sure PB, But Dossy who runs Twitter karma might want a specific number of undeletes per 24 hours SO that he can improve on his application instead causing twitter end users unnecessary issues. As I said this isn't an account issue or an api issue - it's a rules issue and Twitter's insistence of not posting complete and comprehensive rules for everyone everywhere to follow. Regards, Dean
[twitter-dev] Unannounced API change -- new unauthorized errors for blocking users
We believe an unannounced Twitter API change happened today or yesterday, and we just want to fill the group in on our findings. This change caused some consternation from some of our user base (your app doesn't work!), and we want to help preclude that for others. As you know, if user A blocks user B, there's no easy way for user B to know that A has blocked him. On Twitter.com, user B can still view user A's friends, followers, tweet stream, and profile. Before yesterday, as far as we experienced, this used to also be the case for Twitter API calls. That's now changed. If you do authenticated calls for a blocking user, you will receive Unauthorized errors. These calls include statuses/user_timeline, friends/ids, followers/ids, and presumably others. While this change certainly makes sense for the otherwise limited block feature, I have two requests from the Twitter team: 1. Can you please match this behavior on Twitter.com? As it is, users of our app are frustrated because they can, e.g., view the user_timeline of a blocking competitor on Twitter.com, but not through our app. This leads to complaints from users saying our app is broken. 2. Can you please tell us when API changes occur? As it is, the changelog (http://apiwiki.twitter.com/REST-API-Changelog ) hasn't been updated for almost 2 months. Seemingly small changes like this can have significant consequences for apps with larger user bases.
[twitter-dev] Re: Draft: Twitter Rules for API Use
This document needs further detail, specifics, and allowances. 1. Identify the user that authored or provided the Tweet What do you mean by this? Presumably the author of the tweet is the person for whom the tweet appears on Twitter.com and who therefore actually made the tweet or authorized it, right? Isn't that sufficient? Or do you mean, say, that all those vampire bite tweets must identify that they come from vampiresRus.com (or wherever) IN THE TWEET ITSELF? Does a source parameter count as identification, or must the tweet itself contain separate identification along with the content of the tweet? 2. Maintain the integrity of Tweets and not edit or revise them. Wait, we can edit tweets?! I think you need to be more precise with your language and definitions here. In my mind, a tweet is something that appears on Twitter.com, and isn't something which may soon appear on Twitter.com. If Barack Obama says a sentence, it isn't a tweet until it is on Twitter.com. Furthermore, you should get rid of the part where it says edit or revise. It is sufficient to say integrity, particularly as new transformational tools come on line. For example, if a user queues up tweets and indicates that he wishes for them to be translated into Klingon prior to their tweeting, that does constitute edits and revisions to those tweets. But presumably this is acceptable as the user has approved such transformation. Similarly, I think you need to account for the fact that many applications allow the user to approve action-based Tweets where there is no actual text to approve. For example, the Firefox add-ons that let me tweet a particular URL, or one that lets me tweet stock trades I am making, etc. In these cases, I have approved the method to create the tweet (that I press a button and the URL and Title of the page I am on will be tweeted), but I haven't explicitly approved the text of that URL/title (nor would I want to go through that hassle). I would reword the section, then, as something like: Maintain the integrity of the user-approved text to be tweeted, or the process by which the text to be tweeted is created; and do not edit or revise said text, except where the user has specifically approved such transformations. 3. Get each user's consent before sending Tweets or other messages on their behalf. A user authenticating with your application does not constitute consent to send a message. Okay, so what DOES constitute consent? A checkbox that defaults to 'on' with the Tweet? Or a checkbox that defaults to 'off' and which the user can turn on? What about if the user agrees to a long small- type contract wherein it stipulates that the app can tweet on their behalf (yet which the user most likely hasn't fully read)? I think instead of defining what DOESNT constitute consent, you should give examples of what does constitute consent. On Sep 10, 4:58 pm, Marcel Molina mar...@twitter.com wrote: To accompany our updated Terms of Service (http://bit.ly/2ZXsyW) we've posted a draft of the Twitter API rules athttp://twitter.com/apirules. As the subject states, these rules are a work in progress and feedback is welcome. Please read the TOS announcement athttp://bit.ly/2ZXsyWfor some background. We encourage you to use the contact us link athttp://twitter.com/apiruleswith any feedback you may have. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: Recent Following and Follower Issues and Some Background on Social Graph
John: Will the third system be used if, e.g., the user has 1000 friends and we request friends/ids WITHOUT pagination? Or must we include pagination arguments even if 5000 to use the third system? PJB On Sep 7, 9:52 pm, John Kalucki jkalu...@gmail.com wrote: I don't know all the details, but my general understanding is that these bulk followers calls have been heavily returning 503s for quite some time now, and this is long established, but bad, behavior. These bulk calls are hard to support and they need to be moved over to some form of practical pagination scheme. Ideally, we'd offer a stream of social graph deltas on the Streaming API and this polling business could be tightly restricted. Bluntly, until further back-end work is in place, we can return 5k followers reliably from the third system, or we can attempt to return large result sets, but often throw 503s -- really, timeouts, from the second system. We cannot return bulk operations, or use row-based cursors, from the third system. Scraping the social graph is certainly valuable in some cases, but generally it's a low value proposition for users, and scraping is often is used to support abusive behavior. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Sep 7, 9:27 pm, David W. d...@botanicus.net wrote: Hi John, On Sep 6, 3:59 pm, John Kalucki jkalu...@gmail.com wrote: resources. There is minor pagination jitter in one case and a certain class of row-count-based queries have to be deprecated (or limited) and replaced with cursor-based queries to be practical. For now, we're sending the row-count-queries queries back to the second system, which is otherwise idle, but isn't consistent with the first or third system. I am getting several emails per day at the moment from users telling me my app's results are wrong. The application currently asks for the entire follower/following ID list at once, using /followers/ids and / friends/ids. Does this count as a row-count-query? David
[twitter-dev] Re: Recent Following and Follower Issues and Some Background on Social Graph
For now, we're sending the row-count-queries queries back to the second system, which is otherwise idle, but isn't consistent with the first or third system. Can you help us better understand what queries you're talking about? Do you mean, e.g., that any queries that call for *ALL* friends/ids without pagination will use the second inconsistent system? And so the recommended solution would for us to change our queries to use pagination... if we want accurate data?
[twitter-dev] Re: Followers count
The friend/follower counts are TOTALLY off. Why can't new features be introduced without breaking critical existing features? When will this be fixed. Many of us rely on these counts for accurate f/f counts! On Sep 4, 8:49 pm, John Kalucki jkalu...@gmail.com wrote: The 5k limit is a bug. Working to fix. On Sep 4, 6:51 pm, freefall tehgame...@googlemail.com wrote: Until today you could use:http://twitter.com/followers/ids.xml and get the total - this was way more accurate than getting it from user/show. They appear to ahve just lowerd this total to 5000 so that will no longer work (unless that's a bug). On Sep 3, 7:24 am, Waldron Faulkner waldronfaulk...@gmail.com wrote: Same oddness w. friends count as well? I'd guess so. My problem is that if I try to get followers using paging, I get different numbers (and different followers) than if I pull the entire list w/o paging. Also, followers disappear and reappear from one hour to the next. On Sep 2, 5:44 pm, Jason Tan jasonw...@gmail.com wrote: Hello, I have spent a good portion of today reading through closed, merged, and open issues onhttp://code.google.com/p/twitter-api/issues/list I am trying to figure out the best way to get an accurate followers count. Initially, I was using /users/show which returns the full user object, including the followers_count item. However, I have noticed that this number only updates when the user posts a tweet. If the user has no new tweets, the follower count is not updated. Data I was pulling in was many days old. I understand the need to cache data, but being unable to pull up an approximate count of followers from the past several days is a problem. I have seen this issue posted many times, but it is always merged into issue 474, which appears to only deal with the following flag, and not the followers_count. There was one issue (which I can't find anymore) where there was acknowledgment that the users/show data was cached until a new post was made but no mention of any fix or solution. My next approach was to use the statuses/user_timeline. I wasn't sure if the user object for each status would have the current value or the value at the time of the status update. When I grabbed the xml formatted response, I got (starting from the most recent status and going back): 1686, 1653, 1685, 1685, 1685, 1685, 1685... Through the rest of the statuses, it stayed the same. Interestingly, 1686 is the current value listed on the website. 1653 was the value I got from /users/show. And I'm quite certain that the followers count did not stay constant at 1685. Moreover, when I grabbed the json version of statuses/user_timeline, I got entirely different results: 1653, 1653, 1683, 1675, 1652, 1661, 1644... This seems to reflect the current number of followers at the time of the status update, unlike the XML feed. Anyways, to get back to my original question. How do I get an accurate followers count for a user? Also, why are there still XML/ JSON discrepancies (I came across a few reported issues that said they had been resolved). Any help or suggestions would be very much appreciated! Thanks, Jason P.S. The account I was using for the above examples was DailyPHP- Hide quoted text - - Show quoted text -
[twitter-dev] friends/ids now returns w/ 1-5% random duplicates (as of this morning)
The fix to last nights 5000 limit to friends/ids, followers/ids now returns with approximately 1-5% duplicates. For example: User1: followers: 32795 unique followers: 32428 User2: friends: 32350 unique friends: 32046 User3: followers: 19243 unique followers: 19045 NEITHER of these figures comes close to matching what is on Twitter.com. In fact, if I repeat the same calls 10 times for each user (with no following/unfollowing in between), each result is usually different. The duplicates follow either immediately or within 2 or 3 positions after each other. What's strange is that the duplicates are NOT the same if the call is repeated. Please help. This bug is new as of this morning.
[twitter-dev] Re: Can you speak in plain english
$_ =~ s/\-([^\[]+?)\-/process($1)/ges foreach (@tweets); On Sep 2, 6:50 pm, Dante Soiu dsoiual...@gmail.com wrote: And not computer language, Dante Soiu
[twitter-dev] Re: Can you speak in plain english
I think the UK Telegraph (?) article yesterday put it perfectly... the problem is two-fold: Twitter itself is pretty insecure (unfixed javascript hacks, etc), and third-party apps are even LESS secure (non- encrypted db storage of Twitter authentication on mysql injectable hosts, etc etc). My general feeling is that Twitter is going to throw baby out with the bathwater in a desperate attempt to shore up its security. This no doubt will mean that the good apps along with the lousy apps will be thrown to the curb (i.e., blacklisted, or whatever). For those of us relying on Twitter app development as something more than just a hobby, or as something more than a chance to speak computer language, we should really foster a sense of self- regulation that DISCOURAGES the average non-programmer from using Twitter's API. Programming secure, effective, and useful Twitter apps IS VERY HARD. If you don't have expensive programming and db experience, STAY AWAY! This app's NOT for you! On Sep 3, 2:29 am, Nicholas Granado ngran...@gmail.com wrote: PJB ... really? There really no need to flame-bait this thread. I think Scott put it perfectly. Cheers, Nick On Wed, Sep 2, 2009 at 11:37 PM, PJB pjbmancun...@gmail.com wrote: $_ =~ s/\-([^\[]+?)\-/process($1)/ges foreach (@tweets); On Sep 2, 6:50 pm, Dante Soiu dsoiual...@gmail.com wrote: And not computer language, Dante Soiu
[twitter-dev] Problem in past 48 hours: friendships/create severe lag or loss
Woke up this morning to find that several of our users have written in noting that friendship actions taken through our application are not working. We confirmed this problem, across multiple IPs and multiple different apps. Friendships/create works inconsistently: about 30% of the time they work as expected, and the new friends immediately appear in friends/ids API call, as well as when logging into Twitter.com and looking at the new friends pages (we see following). Another 30% appear to be delayed for several hours, during which time a call to friends/ids does NOT show new friends' ids (nor on Twitter.com). Another 30% appears to be lost forever (or severely lagged). All of these friendship creates are returning no errors. A search of @twitterapi on Twitter indicates that this is a (fairly) widespread problem. Can Twitter give us some idea as to when this problem will be resolved? Any chance you can also add a status update for this problem so we can point users to that page?
[twitter-dev] Re: Problem in past 48 hours: friendships/create severe lag or loss
Thanks Jon... can you let us know if past friendships/create (etc) calls that haven't yet worked, will eventually work? Since we database all of these actions, we're worried that we're going to have bad data for the past, e.g., 48 hours, unless those non-error calls actually go through. On Aug 31, 12:03 pm, John Kalucki jkalu...@gmail.com wrote: We're on this. Updates from the usual sources soon. On Aug 31, 11:57 am, David Dellanave david.dellan...@gmail.com wrote: I am pretty sure I am experiencing this issue as well. I can't verify it, yet. I assumed it was an issue with OAuth, but it seems like that it is the same issue.
[twitter-dev] Re: Stop playing around with Source parameters
Hehehe... your regex isn't much better! /a\s+(.*?\s+)?href=[']?(.+?)[']?(\s+.*?)?(.+?)\/a/is On Aug 21, 9:54 pm, Gonzalo Larralde gonzalolarra...@gmail.com wrote: On Sat, Aug 22, 2009 at 1:17 AM, TCI ticoconid...@gmail.com wrote: Recently you added nofollow's, and now you moved the nofollow after the href. Some of us filter these out and you changing them is only making it more complicated. Please make up your mind and stop changing these... a href=http://fun140.com/;Fun140/a a rel=nofollow href=http://fun140.com/;Fun140/a a href=http://fun140.com/; rel=nofollowFun140/a Or, maybe, you can try using this regex: /a.*? href=(.*?).*?(.*?)\/a/ and let them do whatever they want. -- Gonzalo. PS: My english sucks, sorry about that.
[twitter-dev] Re: Join us in the #twitterapi IRC channel on freenode
Usenet, IRC... I am starting to feel like its 1993 all over again! Maybe next we can get a game of Netrek going on NeXt stations! ;) On Aug 18, 3:35 pm, Marcel Molina mar...@twitter.com wrote: We've heard your requests for greater transparency and more frequent communication in the last couple weeks around the fall out from the DDoS attacks. The Twitter Development Talk mailing list and @twitterapi account have gone a long way to keeping the conversation flowing. We want to facilitate even more modes of communication though. So we've opened up the #twitterapi IRC channel on irc.freenode.net. We hope to be able to provide some real-time support when things go awry. Unfortunately, we can't provide 24/7 support via IRC, but we'll try to be around during deploys, unexpected outages, and special events. We also envision it as a place for developers to help each other. So, if you're into IRC, we encourage you to come on over. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: MyTwitterButler.com Legal issues Update 2
The scariest part about all of this, frankly, is less the trademark stuff, and more the fact that he is being punished for violating Twitter's terms and services. As near as I can tell, his app just follows users who tweet certain keywords. It doesn't even UNFOLLOW them (thus potentially churning), it just follows people. Since there are API calls for those actions, many of us have built rich apps around follow. Indeed, Twitter DOES support mass following... if not, why would batch following be in their roadmap (http://apiwiki.twitter.com/V2-Roadmap#Following )... To now see another app taken down because of supposed API violations around mass following is very scary. And what's even MORE scary is the selectivity of it. Why was this little guy taken down? What about, say, the popular downloadable XYZ app which apparently does what tweetbutler does and then some? Do they have some more formal relationship with Twitter? Or do their other apps somehow inculcate them against violating TS? It's a minefield out there, and that's VERY VERY scary. Who knows if the API calls you make today might violate terms and services tomorrow? Perhaps you can count your lucky stars if you have casual email correspondence with a Twitter engineer... maybe that's what's needed to fend off trouble? And too bad for those guys over in England, like this guy, who perhaps didn't have such a relationship!
[twitter-dev] Re: MyTwitterButler.com Legal issues Update 2
This is all rather scary, especially for those of us dedicating significant resources to Twitter-related development. I was having a new logo designed... it was going to be in light blue. I guess I will have to reconsider that option now!
[twitter-dev] problem: friends/ids occasionally returning empty sets
Before I bring you back to your regularly scheduled programming concerning intellectual property issues and whether or not someone may or may not be sued, I do have something API-related... Is anyone else experiencing problems today with friends/ids and followers/ids returning empty sets, yet with no errors? The JSON returned does not time out and is well-formed, but there are zero ids returned, when the queried for user clearly has friends/followers. This problem occurs intermittently. Anyone else?
