[twitter-dev] Re: API Changes for August 12, 2009
Alex, Thanks for this update, this is a welcome change! -Bob On Thu, Aug 13, 2009 at 3:21 PM, Alex Payne wrote: > A day late and a bug short... > > FIXED: /account/verify_credentials no longer enforces a rate limit that's > inconsistent with the rest of the API. > > Thanks. > > -- > Alex Payne - Platform Lead, Twitter, Inc. > http://twitter.com/al3x >
[twitter-dev] Re: comsumer Keys and comsumer secret--an "OAUTH" issue on twitter
try http://127.0.0.1/ it shouldn't make any difference but who knows. -Bob On Wed, Aug 12, 2009 at 10:31 PM, techyJoe wrote: > > I am unable to register my application with twitter. twitter will not > accept my Callback URL, it states that it is a n invalid URL. I am > using a test server at this point, and it is set for "localhost"; > however, I use the same callback URL for other API and they work fine. > The URL should be valid. > > Any help would be appreciated!! > > jsalinas >
[twitter-dev] Re: FW: Twitter is Suing me!!!
Obligatory Wikipedia link: http://en.wikipedia.org/wiki/Ontology On Wed, Aug 12, 2009 at 7:14 PM, Neil Ellis wrote: > > Someone remind me again who was it that saw this record breaking thread > coming . :-) > > I think the only thing that hasn't been discussed is the very nature of life > itself :-) > > peace > Neil > > On 12 Aug 2009, at 23:04, Gonzalo Larralde wrote: > >> >> On Tue, Aug 11, 2009 at 11:48 PM, Dean Collins wrote: >>> >>> Any other developer being sued by Twitter today? >> >> "Basically it's a WINDOWS XP .net application, if you have a mac and >> you stupidly purchase this and it doesn't workgo bitch to Steve >> Jobs." [0] >> >> "If you buy this and it doesn't do what you thought it was supposed >> togo bitch to your mother." [0] >> >> I hope they win. ¬¬ >> >> >> [0] http://www.mytwitterbutler.com/ @ About Me > >
[twitter-dev] Re: FW: Twitter is Suing me!!!
Just because in all cases you can't define premeditated murder doesn't mean that premeditated murder isn't universally wrong. "One person considers being followed by someone they don't want to be followed by to be spam. Others don't." Very true, however when you ask that same person if being followed by 100 or 1000 people that they don't want to be followed by as spam I would be surprised if anyone said no and that is the behavior this app encourages. "To blame a tool that enables people to follow someone is like blaming the gun for killing. That's just downright stupid, or in this case, universally wrong. Again very true, however one needs to use some common sense. It's ok for people to own guns. It's not ok for people to own nuclear missiles or anthrax. Why is that? We don't blame those tools for killing... We ban there ownership because they have no legitimate use for every day normal people. My Twitter Butler falls into the nuclear missile category. I can think of no legitimate uses for wanting to follow 400 people who input any keyword. You could make the case of a niche market, I mean if you wanted to connect with people who liked to fly fish in dubai then you could look for #flyfishingindubai but with the smallness of that group the twitter web interface and manually following works just fine. At any scale where you need an app to follow people based on keywords the uses are only malicious. The only scenario I can think of that is legitimate is to compare other tweets of those who are interested in one topic. Ie if people mention #Dell what other habits do they have? However this behavior can be achieved by running searches for #Dell, culling the user names and accessing their streams directly alleviating the need for mass following. If there is a use case I haven't thought of please feel free to enlighten me. Also as a final note, I've never heard of your application nor do I have any knowledge of what it does (and I'm intentionally not going to look until this thread is done) so I don't want you to think this is a personal attack. I'm just trying to observe the reason for the TOS violation and make a case for why it is a reasonable part of the TOS. -Bob On Wed, Aug 12, 2009 at 4:23 PM, Dossy Shiobara wrote: > > On 8/12/09 3:44 PM, Robert Fishel wrote: >> >> There are universal wrongs. Guns aren't on of them. Premeditated murder >> is. >> So is spam. > > Suppose you're right. Is it so very clear what premeditated murder is in > all cases? How about spam? > > One person considers being followed by someone they don't want to be > followed by to be spam. Others don't. > > To blame a tool that enables people to follow someone is like blaming the > gun for killing. That's just downright stupid, or in this case, universally > wrong. > > Users abusing tools can be destructive and we should define ways of handling > those abuses - trying to ban or eliminate those tools is pointless. > > In developing and maintaining Twitter Karma, I have been very careful in > selecting what features to implement. I recognize that it can still be used > by people to abuse Twitter and that makes me very, very sad. However, those > features are also very useful for legitimate users, so I have implemented > them. I will, however, refuse to implement any feature that only benefits > users who intend to abuse Twitter. > > In the end, I would hope that Twitter would create ways of punishing the > abusive users and not Twitter Karma. > > -- > Dossy Shiobara | do...@panoptic.com | http://dossy.org/ > Panoptic Computer Network | http://panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70) >
[twitter-dev] Re: FW: Twitter is Suing me!!!
No I don't see what you did there There are universal wrongs. Guns aren't on of them. Premeditated murder is. So is spam. Maybe I'm slow but what are you trying to get at? -Bob On Wed, Aug 12, 2009 at 2:32 PM, Dossy Shiobara wrote: > *SNIP* > Universal wrongs? > > YOU are WRONG. > > Guns don't kill people. People kill people. > > See what I did there? > > -- > Dossy Shiobara | do...@panoptic.com | http://dossy.org/ > Panoptic Computer Network | http://panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70) >
[twitter-dev] Re: Rate limit question (again/followup) 20k user or ip?
While this may be true I think it's a fringe case and not what we're trying to get at here (although it could explain conflicting test results) To summarize what we're looking for clarification on: (example) My server has 1 whitelisted IP and 1000 users. It operates for 1 hour. Each user makes an equal number of requests. Is the limit 20 requests per user (= 20k per hour per ip) or Is the limit 20k per user (=20k per hour per user) The only reason I'm kind of harping on this is that for the new app I'm developing the latter would save me a lot of heartache and quite a bit of money. Cheers, Bob On Tue, Aug 11, 2009 at 1:54 AM, TFT Media wrote: > > > I believe sometimes the IP address can be user-based, even for white- > listed IPs. E.G., if the user himself has a whitelisted IP. > > On Aug 10, 7:57 pm, Dewald Pretorius wrote: >> Jim, >> >> I don't know exactly what you're looking at and how you get to that >> answer. >> >> My system is making thousands of GET calls per hour, and I can see how >> X-RateLimit-Remaining is decrementing regardless of which Twitter user >> credentials are used. >> >> So, on my side I am seeing solid evidence that the rate limit is per >> IP address only and not per user. >> >> Dewald >> >> On Aug 10, 11:26 pm, "jim.renkel" wrote: >> >> > Hmmm! We seem to have conflicting evidence here! >> >> > I just (again) verified that twxlate.com is getting 20k requests per >> > hour per user. >> >> > How long ago was it that Alex and other API team members made the >> > recommendation that you mentioned? Is it possible that twitter changed >> > policy since then? >> >> > Either way, I agree that we now need a very clear affirmation from >> > twitter as to the policy. >> >> > I sure hope I don't have to eat my words! :-) >> >> > Jim >> >> > On Aug 10, 9:08 pm, Dewald Pretorius wrote: >> >> > > On Aug 10, 11:02 pm, "jim.renkel" wrote: >> >> > > > My logic is now: "Ifratelimiting is not peruser, then all users of >> > > > anIPaddress will share one pool of20krequests per hour. If a site >> > > > has a 1,000 users at one time, then eachuserwill get an average of >> > > > 20 requests per hour. This is clearly not enough to do much useful. >> >> > > Jim, >> >> > > That is why Alex and other API team members have recommended in the >> > > past that you get and use additional white-listedIPaddresses, when >> > > 20,000 requests per hour perIPaddress is not sufficient to service >> > > youruserbase. >> >> > > At TweetLater I employ several white-listedIPaddresses to cover the >> > > needs of my users. >> >> > > Dewald >
[twitter-dev] Re: Account Verify Credentials
Except that this case fails for calls such as statuses/friends if the user isn't authenticated but you think he is you get a completely valid (from one point of view) set of results back but they do not include any protected users. Therefore a call to verify_credentials is necessary to ensure that you are processing the correct data. -Bob On Thu, Aug 6, 2009 at 10:36 PM, Chris Babcock wrote: > > On Thu, 6 Aug 2009 12:01:14 -0400 > Robert Fishel wrote: > >> I too thought that one should call verify credentials with Oauth. How >> are you suggesting we verify that the token is still active, another >> call to oauth_authenicate/authorize? > > The oauth_authenicate and oauth_authorize calls are not rate limited. > They can't be used to hack user credentials, so they don't need to be. > > Authentication is a once per session event. Once authenticated, a user > remains authenticated to your app until your own session controls > expire. This is independent of the user's Twitter session, except that > the user needs to be authenticated with Twitter in order for Twitter > to authenticate the user to your app. This happens once, at the > beginning of the user's session with your app and it is not subject to > a DoS attack on the account/verify_credentials service. > > It may be useful to verify that an authorization token has been > activated, but checking authorization before a call that will fail if > the authorization is not available is wasted bandwidth. You should > check after the call to see if the action succeeded. It's more reliable > and lower bandwidth. > > Chris Babcock > >
[twitter-dev] Re: local dev + sub-domains and oauth
Perhaps set a cookie when they come to your site noting their preferred language then check for the cookie on the callback page. -Bob On Thu, Aug 6, 2009 at 12:35 PM, peter_tellgren wrote: > > I am running a site where I use sub-domains for the different > languages I support on the site. > > e.g. en.example.com/.. for English and fr.example.com/.. for French > > I just wonder if I go from my en.example.com/twitter site to the > twitter to have my user accept my site as a consumer do I have to have > a callback URL to en.example.com/twitter_callback or do I in the best > way solve this. > > I assume there must be a better way since I am not to eager of > creating one app for each language. Any tips welcome. > > Also today when I created a new app on the twitter site and added a > callback URL and app URL that are local to my machine. I got a pin > code instead of a callback. I tried to remove the app with and adding > it again with the same result. Is there a temporary glitch in the > twitter API or am I missing something? > And this afternoon I am unable to update my Twitter App: > > I go to http://twitter.com/apps, enter my app that I want to edit. I > do my changes but when I click save It does not work. > > Any ideas on these topics are welcome > >
[twitter-dev] Re: Rate Limiting Question
Well it seems as though Twitter is saying that 20k calls per user is the intended functionality. Chad or someone else can you confirm this? Also if the correct functionality is 20k per ip per hour will you then fail over to 150 per user per hour or is it cut off? Thanks -Bob On Thu, Aug 6, 2009 at 7:54 AM, Dewald Pretorius wrote: > > Bob, > > Don't base your app on the assumption that it is 20,000 calls per hour > per user. > > You get 20,000 GET calls per whitelisted IP address, period. It does > not matter if you use those calls for one Twitter account or 10,000 > Twitter accounts. > > If the API is currently behaving differently, then it is a bug. > > I have had discussions with Twitter engineers about this, and the > intended behavior is an aggregate 20,000 calls per whitelisted IP > address as I mentioned above. > > Dewald > > On Aug 6, 4:09 am, Robert Fishel wrote: >> Wowzers (bonus points for getting the reference) >> >> It appears as if each user does get 20k (according to the linked >> threads) this is I think what they intended and makes apps a LOT >> easier to develop as you can now do rate limiting (ie caching and >> sleeping etc...) based on each user and not on an entire server pool, >> makes sessions much cleaner. >> >> I am whitelisted and I'll test this tomorrow evening to make double >> sure but this sounds great!. >> >> Thanks >> >> -Bob >> >> On Thu, Aug 6, 2009 at 2:53 AM, srikanth >> >> reddy wrote: >> > With a whitelisted IP you can make 20k auth calls per hour for each user. >> > Once you reach this limit for a user you cannot make any auth calls from >> > that IP in that duration. But the user can still use his 150 limit from >> > other apps. >> >> >http://groups.google.com/group/twitter-development-talk/browse_thread... >> >> > On Thu, Aug 6, 2009 at 7:50 AM, Bob Fishel wrote: >> >> >> From the Rate Limiting documentation: >> >> >> "IP whitelisting takes precedence to account rate limits. GET requests >> >> from a whitelisted IP address made on a user's behalf will be deducted >> >> from the whitelisted IP's limit, not the users. Therefore, IP-based >> >> whitelisting is a best practice for applications that request many >> >> users' data." >> >> >> Say for example I wanted to simply replicate the twitter website. One >> >> page per user that just monitors for new statuses with authenticated >> >> (to catch protected users) calls to >> >>http://twitter.com/statuses/friends_timeline.json >> >> >> Say I was very popular and had 20k people on the site. Would this >> >> limit me to 1 call per minute per user or would it fall over to the >> >> user limit of 150 an hour once I hit my 20k? If so how can I tell it >> >> has fallen over besides for simply keeping track of the number of >> >> calls per hour my server has made. >> >> >> Thanks >> >> >> -Bob
[twitter-dev] Re: Account Verify Credentials
Chris, I too thought that one should call verify credentials with Oauth. How are you suggesting we verify that the token is still active, another call to oauth_authenicate/authorize? Thanks -Bob On Thu, Aug 6, 2009 at 7:51 AM, Chris Babcock wrote: > > > > On Aug 5, 10:15 pm, Jesse Stay wrote: >> On Wed, Aug 5, 2009 at 3:04 AM, Chris Babcock >> wrote: >> >> >> >> > I would strongly recommend OAuth for verifying users, or at least >> > making it an option, as there is a DoS attack possible against service >> > providers who rely on this API for access to their app. >> >> > Chris Babcock >> >> I'm not sure how OAuth helps, as the problem still exists, even with OAuth >> users. Even with OAuth, it is still 15 requests per user per hour on >> verify_credentials. Of course, you probably don't have to run >> verify_credentials as often with OAuth, but the problem still exists, and >> there are cases where I can see this could become an issue. >> >> Jesse > > No, you *never* use verify_credentials with OAuth because you never > handle user passwords. > > Take for example those users whose accounts are being slammed by > SpamBots. They can still log into Twitter, just not those services > that rely on verify_credentials service. Because they can still log in > on the Twitter site, they could still authorize OAuth tokens. You will > know that they have valid credentials on Twitter if the token has been > authorized when they return to your site. It's not necessary for your > app to obtain and verify the credentials directly. Your app can > completely bypass the rate limited service with its DoS potential. > > Chris Babcock > >
[twitter-dev] Re: Rate Limiting Question
Wowzers (bonus points for getting the reference) It appears as if each user does get 20k (according to the linked threads) this is I think what they intended and makes apps a LOT easier to develop as you can now do rate limiting (ie caching and sleeping etc...) based on each user and not on an entire server pool, makes sessions much cleaner. I am whitelisted and I'll test this tomorrow evening to make double sure but this sounds great!. Thanks -Bob On Thu, Aug 6, 2009 at 2:53 AM, srikanth reddy wrote: > With a whitelisted IP you can make 20k auth calls per hour for each user. > Once you reach this limit for a user you cannot make any auth calls from > that IP in that duration. But the user can still use his 150 limit from > other apps. > > http://groups.google.com/group/twitter-development-talk/browse_thread/thread/d1664c633972a7c1/9f49c1ad096e9139?lnk=gst&q=API+rate+limit#9f49c1ad096e9139 > > On Thu, Aug 6, 2009 at 7:50 AM, Bob Fishel wrote: >> >> From the Rate Limiting documentation: >> >> "IP whitelisting takes precedence to account rate limits. GET requests >> from a whitelisted IP address made on a user's behalf will be deducted >> from the whitelisted IP's limit, not the users. Therefore, IP-based >> whitelisting is a best practice for applications that request many >> users' data." >> >> Say for example I wanted to simply replicate the twitter website. One >> page per user that just monitors for new statuses with authenticated >> (to catch protected users) calls to >> http://twitter.com/statuses/friends_timeline.json >> >> Say I was very popular and had 20k people on the site. Would this >> limit me to 1 call per minute per user or would it fall over to the >> user limit of 150 an hour once I hit my 20k? If so how can I tell it >> has fallen over besides for simply keeping track of the number of >> calls per hour my server has made. >> >> Thanks >> >> -Bob > >
[twitter-dev] Re: follwers ids and friends ids
I'm pretty sure this is a verified bug with the number of followers not being exact but I can't seem to find the reference anywhere... -Bob On Sun, Aug 2, 2009 at 11:11 PM, Dan Kurszewski wrote: > > I am having problems with the followers ids and friends ids calls. > > reprosites has 6318 friends and 5960 followers. > > If I do a regular call with no paging I get the proper results. > > But if I page some wierd stuff happens. > > http://twitter.com/friends/ids/reprosites.xml?page=1 returns 5000 > results like expected. > http://twitter.com/friends/ids/reprosites.xml?page=2 returns nothing > when it should at least have some results. > > http://twitter.com/followers/ids/reprosites.xml?page=1 returns 5000 > results like expected. > http://twitter.com/followers/ids/reprosites.xml?page=2 returns nothing > when it should at least have some results. > > Could someone please let me know what I am doing wrong? > > Dan >
[twitter-dev] JS API implementation
Can anyone recommend a javascript api implementation (anything that already has a jquery plugin would be a bonus but not necessary) The few I've seen don't allow statuses.update which is a nessecity for me. Thanks
