[twitter-dev] Re: Private user's 'following' information: why am I denied access via API but can get through Twitter.com?
Yes, this is still the case. I thought for sure Tweet Thief was missing something obvious, but when I went and tried it, he is 100% correct! I agree with him that this is a serious bug that needs to be fixed. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Raffi Krikorian Sent: Wednesday, September 30, 2009 14:12 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: Private user's 'following' information: why am I denied access via API but can get through Twitter.com? is this actually the case? http://apiwiki.twitter.com/REST+API+Changelog on the 15th of september, this issue may have been cleared up. > > > 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 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_hi&user_b=tw >> ..." >> >> Results in: >> >> HTTP/1.1 403 Forbidden >> Status: 403 Forbidden >> (irrelevant headers edited) >> >> >> >> /friendships/exists.xml? >> user_a=just_me_hi&user_b=tweetthief >> You do not have permission to retrieve following status for >> both specified users. >> >> >> 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 -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] Re: Improving the UX of Twitter+Oauth on iPhone?
I created an enhancement request for this: http://code.google.com/p/twitter-api/issues/detail?id=1011 and al3x has said "We have a solution for this in progress.". Please visit the issue and star it to bump its priority within twitter. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Tuesday, September 29, 2009 20:04 To: Twitter Development Talk Subject: [twitter-dev] Re: Improving the UX of Twitter+Oauth on iPhone? If my understanding is correct, the only way you can imitate Facebook connect when using Twitter OAuth, is to scrape the Twitter login page and authorization page and hide them from the user, i.e., login on behalf of the user, and authorize on behalf of the user, assuming that you first ask the user for his Twitter username and password (which side-steps one of the major proclaimed benefits of OAuth in that the user never has to give his credentials to your app). I think Twitter will bitch-slap you if you do that. Dewald On Sep 29, 9:45 pm, "joeygreen...@gmail.com" wrote: > I'm implementing both facebook connect and Twitter+Oauth for an > iPhone app I'm currently working on. I really like the way facebook > connect makes it seem that you're still in the app and not visiting > some external website. Also, it kind of messes with the flow of my app > because when you sign into facebook connect you have this snappy > interface and when you sign into Twitter+Oauth you can really notice > that you're being redirected to a website. > > So, what I'm wanting to do is make my Twitter+Oauth process be more > like, if not identical, to how facebook connect works. My question is, > does the user need to know that they are going to twitter to login? > Most users are probably unaware that they are using a webpage when > they are using facebook connect. > > In my scenerio, would it be better to imitate the facebook connect > experience or just keep it where you know you're being sent to twitter?
[twitter-dev] Re: First time working with OAuth want to do some automated stuff
In answer to your question "Is there a way to automatically get the access tokens without me making a web page that will ask me to login to twitter and authenticate?", I requested this as an enhancement. Here's the URL to the request: http://code.google.com/p/twitter-api/issues/detail?id=1011 Al3x replied that they are working on something to help us out here, but no ETA promised. You may want to visit the issue and star it to give it a little more weight. Thanks, Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Abraham Williams Sent: Tuesday, September 29, 2009 01:26 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: First time working with OAuth want to do some automated stuff On Mon, Sep 28, 2009 at 18:50, Hintswen wrote: I currently have a script running on my server using basic authentication and tweeting rss feeds to a number of different accounts. I want to do something similar to that but using OAuth (seeing as I cant register an application for basic auth anymore). But I'm lost, OAuth requires a browser to work doesn't it? but my script wont be run from a browser. I'm not sure if you are using PHP but here is a blog post about running server scripts with OAuth: http://kovshenin.com/archives/automatic-tweet-oauth/ Do I have to make an authorize page and load that in a web browser to get the access tokens and then put them into my script? Yes. Will they ever expire? No. Is there a way to automatically get the access tokens without me making a web page that will ask me to login to twitter and authenticate? You could write an HTML parser to parse the authorization page but that would be a lot of work and error prone. Abraham -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, WI, United States
[twitter-dev] Re: About the oneforty application directory
I too could be wrong, and often am, but I don't see anything in the OAuth specification (http://oauth.net/core/1.0a) about what an access token could or does allow access to, i.e., reading resources as opposed to reading and writing resources. The spec seems to be completely silent on the "granularity" of access that is granted to resources via its mechanisms. So I think twitter would be perfectly legitimate in granting authentication only, authentication and read access, and authentication and read and write access "levels" of authorization. I have previously proposed that the ability to geocode tweets be an additional level of authorization, and I could also see additional levels, or orthogonal capabilities, for, e.g., enabling geo-coding, access to e-mail addresses and device phone numbers, etc. Comments expected and welcome. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of JDG Sent: Monday, September 28, 2009 17:20 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: About the oneforty application directory Unfortunately, best as I can ascertain, that would violate the OAuth spec (I may, of course, be wrong -- I often am :-) ). There are RW tokens and RO tokens, but no Auth-only tokens. The best you could hope for, given the current state of the spec, would be for an app to simply get, then discard, the Access token. This is a good use case for OAuth, and perhaps should be brought up with them as a scenario for future versions of the spec. On Mon, Sep 28, 2009 at 14:47, Jim Renkel wrote: Yes, you can check the "Yes, use Twitter for login", or not. I'm not sure what this does, either way. But you have to select one of the "Read & Write" or "Read-only" radio buttons under the "Default Access type:" heading. There doesn't appear to be any way to turn them both off. So it seems you have always request (and receive) at least read access to the data of user's that authorize your application to act for them on twitter. This is what I and others were trying to point out, and object to: you can't authorize without granting read access. Why authorize without granting read access? Just to verify that they are the twitter user they claim to be, without reading, or writing, any of their data. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Brian Smith Sent: Monday, September 28, 2009 09:32 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: About the oneforty application directory Dossy Shiobara wrote: > It would be nice if Twitter made "authentication only" as an option for > OAuth. Twitter already has this. It is called "Sign in with Twitter." - Brian -- Internets. Serious business.
[twitter-dev] Re: About the oneforty application directory
Yes, you can check the "Yes, use Twitter for login", or not. I'm not sure what this does, either way. But you have to select one of the "Read & Write" or "Read-only" radio buttons under the "Default Access type:" heading. There doesn't appear to be any way to turn them both off. So it seems you have always request (and receive) at least read access to the data of user's that authorize your application to act for them on twitter. This is what I and others were trying to point out, and object to: you can't authorize without granting read access. Why authorize without granting read access? Just to verify that they are the twitter user they claim to be, without reading, or writing, any of their data. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Brian Smith Sent: Monday, September 28, 2009 09:32 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: About the oneforty application directory Dossy Shiobara wrote: > It would be nice if Twitter made "authentication only" as an option for > OAuth. Twitter already has this. It is called "Sign in with Twitter." - Brian
[twitter-dev] Re: cursor support for blocks functions
I agree. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of J. Dale Sent: Sunday, September 27, 2009 09:57 To: Twitter Development Talk Subject: [twitter-dev] cursor support for blocks functions A couple of the users of my application have enough blocked users that I'm having the same type of timeout/over capacity problems with blocks/ blocking and blocks/blockingids that folks were having statuses/ followers. statuses/friends, friends/ids and followers/ids. Any chance the cursor parameter will be added to the blocks calls?
[twitter-dev] Re: About the oneforty application directory
I agree! Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dossy Shiobara Sent: Sunday, September 27, 2009 14:08 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: About the oneforty application directory Frankly, I don't even like the idea of read-access for an application like this. It would be nice if Twitter made "authentication only" as an option for OAuth. Better would be an option on the accept/deny OAuth page where users can select what access to grant to an application - defaulting to perhaps what access the application desires. On 9/25/09 8:04 PM, Jim Renkel wrote: > What will you be using my twitter account for, other than authorization? > If you reregister the site to only need read access to my twitter > account, I would be a lot less reluctant to use it. -- 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: broken links
While valid URLs, both "http://is.gd/3HsuO,http://is.gd/3HsuO,%3Ca"; give 404 errors when followed, while "http://is.gd/3HsuO"; gets a page view. You have to validly delimit URLs when you include them in tweets. If twitter did a shortening on you, then they may have a problem. If you did the shortening (which I think is the case, twitter would have used http:/bit.ly/...) then you need to be more careful when you compose your tweets. I could be all wrong about this, but I hope it helps. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Alan Samet Sent: Saturday, September 26, 2009 15:07 To: Twitter Development Talk Subject: [twitter-dev] broken links My tweets all have broken links right now. here are a few of them: http://is.gd/3HsuO,http://is.gd/3HsuO,%3Ca http://is.gd/3HjBL,http://is.gd/3HjBL,%3Ca http://is.gd/3HjfP,http://is.gd/3HjfP,%3Ca can you look at this issue, please? Thanks in advance, Best Regards
[twitter-dev] Re: Twitter Rate Limit for IPs
I'm guessing that if you do a request that counts against your rate limit (rate_limit_status requests do not) from just 1 of your IPs, and then request the rate limit status on each of them, you will see that the one that made the non-rate_limit_status request now has 19,999, while the other two still have 20,000. My understanding is that each white-listed IP gets 20k authenticated GET requests per hour per authenticating account and an extra 20k non-authenticated GET requests per hour, whether the IPS are listed for the same account or not. As I understand it, across your 3 IPs, you should get 60k authenticated requests per hour per authenticating account, and an extra 60k non-authenticated GET requests per hour. Let us know what you find, as I've never heard about rate limit issues from someone with more than one white-listed IP. Hope this helps. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of TwitterNoob Sent: Saturday, September 26, 2009 05:02 To: Twitter Development Talk Subject: [twitter-dev] Twitter Rate Limit for IPs Hi, I recently got whitelisted for 3 IPs which is listed under one single account. Does this mean that each IP will have a rate limit of 20,000 requests/hour for the REST API so collectively all 3 IPs should give 60,000 requests/hour for the REST API or does this mean that all 3 whitelisted IPs under one single account will have 20,000 requests/ hour for the REST API collectively? I used this command "curl -u user:password http://twitter.com/account/rate_limit_status.xml"; to get the rate limit status for each of the 3 servers with those IPs but it seems like all 3 IPs have only 20,000 requests/hour collectively. I'm a little confused about this because initially I thought that each IP whitelisted should give me an additional 20,000 requests/hour but maybe I'm wrong so I would greatly appreciate it if someone can answer this or show me a better way of querying for the rate limit status of each individual server. Many thanks to the benevolent stranger(s) for answering this...
[twitter-dev] Re: SERIOUS Problem With Cursors In JSON Followers/Friends Ids
+1. For this and other reasons the API should be versioned. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott Haneda Sent: Friday, September 25, 2009 21:28 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: SERIOUS Problem With Cursors In JSON Followers/Friends Ids Why is the API not versioned then? api.twitter.com/?v=1, api.twitter.com/?v=1.1, api.twitter.com/?v=1.2 etc Or, if that is too much maintenance, how about api.twitter.com/?bitfix=32 or whatever. -- Scott * If you contact me off list replace talklists@ with scott@ * On Sep 25, 2009, at 6:40 PM, JDG wrote: > and it would also break everyone who CAN handle 64 bit ints and > expects > results in decimal numeric format. > > On Fri, Sep 25, 2009 at 16:01, Richard wrote: > >> >> Can this not be returned as hex or base64? >> It would save bandwidth for Twitter (and us) and make it a string >> people could convert it to 64bit int if they still want to. >> >> On Sep 25, 10:16 pm, Scott Haneda wrote: >>> I would not change either. But there are those here that are >>> stating >>> they need new hardware to work around this issue, and that they can >>> not afford that. I was trying to be that voice of reason if that is >>> the road/excuse they are choosing to go. >>> >>> There seem to be acceptable workarounds, solid proposed workarounds, >>> etc. I guess I am not getting it, JSON is just a string returned, >>> yes, it can represent type of data, but it is still just a >>> string. I >>> can not see it being that huge a performance hit to massage that >>> string a bit once you get ahold of it. >>> -- >>> Scott * If you contact me off list replace talklists@ with scott@ * >>> >>> On Sep 25, 2009, at 2:02 PM, jmathai wrote: >>> >>>> It's ridiculous to suggest a change in hardware (64 bit) or >>>> software >>>> (switch from PHP) to use Twitter's API. It's not like either of >>>> these >>>> are archaic. It sucks, sure, but it's silly to suggest such a >>>> "solution". >>> >>>> BTW, I don't have this problem. I'm just trying to be the voice of >>>> reason. >
[twitter-dev] Re: Please Make 401 Singular In Meaning
Agree. Completely. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Friday, September 25, 2009 20:05 To: Twitter Development Talk Subject: [twitter-dev] Re: Please Make 401 Singular In Meaning And if anyone is going to tell me I should make additional API calls to try and determine the real source of the error, or I should try and interpret the returned error message, I am going to remotely install a VB program on your laptop that is going to repeatedly pick up the mouse and whack you over the head with it. What I am really saying is the API is returning a false error message. The user is properly authenticated. The error is that the target information resource does not exist. That's why it must return 404. Try it for yourself and see what I mean: curl -u username:password http://twitter.com/statuses/user_timeline/broughtin.json Dewald On Sep 25, 9:51 pm, Dewald Pretorius wrote: > API folks, could you please, please NOT return 401 "Not authorized" > when an authenticated call with a perfectly valid username and > password requests a /queryusername.json where that queryusername > happens to be a username that does not exist. > > Rather return 404. > > By returning 401 you are making it impossible for me to tell where the > actual problem lies and inform the user. Is it with the user's > password, or is it because the user wanted information about a Twitter > account that does not exist? > > Dewald
[twitter-dev] Re: About the oneforty application directory
oneforty.com seems like a valuable and useful site, one I would
definitely take advantage of, but I have a couple of questions and
concerns that need to be answered before I do so.
1. I'm not sure why I have to grant the site access to a twitter account
to use, and I am REALY concerned about why it needs update access, not
just read access. I don't want this site, or any other site like it, to
be able to update my twitter account, generating tweets or DMs, etc.,
until I see what the benefit of it doing so is.
What will you be using my twitter account for, other than authorization?
If you reregister the site to only need read access to my twitter
account, I would be a lot less reluctant to use it.
2. The site seems to be geared toward client applications. My
application is, for now, just a web-site (http://twxlate.com) with the
possibility of it evolving into desktop and smart phone client
applications in the future. Is your intention to be as relevant to
web-sites as to client applications?
Thanks in advance.
Jim Renkel
-Original Message-
From: twitter-development-talk@googlegroups.com
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Alex
Payne
Sent: Thursday, September 24, 2009 14:24
To: Twitter Development Talk
Subject: [twitter-dev] About the oneforty application directory
Just wanted to pass on a note from the team at oneforty.com, who
recently launched with over 1300 Twitter applications in their
directory. Your app might already be on their site. If it's not yet,
you can register as a developer and add it. Once you register and
claim your app you can promote it with screenshots, descriptions,
tags, and reviews.
If you saw the early alpha version of oneforty, it's much improved -
real home page, most popular apps ranking and essentials. New item
pages just launched and look much better than the prototype did.
Their team working on the ability to sell apps right on the site.
They're also definitely looking for your feedback. @freerobby,
@graysky, @macasek, and @pistachio are often in the #twitterapi IRC
channel. There's more contact info below, too.
A note from the oneforty team and info on how to register, claim, edit
& add stuff:
"""
We built oneforty to help the best stuff being built on the Twitter
API get found and get profitable.
Come claim your apps, add content and add new projects in the "Twitter
appstore" oneforty.com
To get started:
Sign in via oauth. (We whitelisted as many dev usernames as we could
find. If you can't login already use invite code TWAPI and we'll let
you right in.)
Register as a developer: http://oneforty.com/me/developer_profile
Search for and claim your app ("Suggest Item" if we don't have it
yet!)
Check out your item's page, make sure it's tagged well, tweet a link to
it, etc
Once approved, add details, screenshots, media coverage and more
In the near future you'll be able to offer things for sale right in
oneforty. For now we link to your sites and (optionally) let you
collect donations.
We want to help you get your app found, rated, reviewed and into the
hands of the users who need it the most. We also want to get the
Twitter community to do a better job supporting developers and apps so
that your innovation can flourish. It's frustrating when great apps go
defunct because of server costs, etc.
We're anticipating decent blog and press coverage, so we want your to
look its best! Please let us know whatever we can do to help you.
Thank you.
We'd really love to know what you think and what you want: Uservice
feedback forum. Any questions at all, develop...@oneforty.com or
617-645-7767, anytime.
oneforty Founder Laura (@Pistachio) Fitton will be at events in Fort
Worth 9/25, Seattle 9/26-27, SF/bay area 9/27-30 and Boston 10/1 and
would love to meet you (see http://bit.ly/tour140 for Tweetup & event
info). She also wrote Twitter for Dummies.
"""
Check 'em out!
--
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x
[twitter-dev] Re: SERIOUS Problem With Cursors In JSON Followers/Friends Ids
"creat[ing] any large numeric values in the JSON output as strings" could potentially break existing JSON-using applications, depending on the library they use and how they have "typed" the variable to receive the large numeric value. For http://twxlate.com, I use Google's GSON library (http://code.google.com/p/google-gson/), and, if I had typed my variables (actually, Java class fields) as int, Integer, long, or Long, then the change you suggest would break my code. Of course the code would also have been broken when the values exceeded 2**31 or 2**63. Anticipating this and also possibly non-numeric values, I typed the fields as Strings. So I have lucked out on the impact of Twitpocalylses. But others may not have been or be so lucky. On a higher plane, to my mind this is an issue of versioning in the API syntax. Twitter does not support explicit versioning (i.e., the inclusion of an API version parameter in API requests) as other RESTful interfaces do. For example, most Google API RESTful interface methods include a v= parameter to indicate which version of the method is being used. If twitter included this, then to receive large numeric values encoded as strings the requester could simply include, e.g., v=1.1, on the request. Given that twitter specified in advance that if you request version 1.1 responses then large numeric values would be encoded as strings, then any request made with v=1.1 would have known and had to be prepared to accept string encoded values. Without v=1.1, you would still get integer encoded values, and nothing would break. There have been, and I suspect will continue to be, changes to the API specification that were or will be not backward compatible without a version parameter, and for this reason I strongly urge twitter to adopt this mechanism for all non-backward compatible API changes. Version negotiation could also be done via HTTP headers, but I prefer method parameters. Comments expected and welcome. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Thursday, September 24, 2009 10:26 To: Twitter Development Talk Subject: [twitter-dev] Re: SERIOUS Problem With Cursors In JSON Followers/Friends Ids Provided that it will not break the JSON for other language apps, the solution is extremely simple for Twitter to implement, and it will save a lot of us a lot of work and expense. Just create any large numeric values in the JSON output as strings, instead of numbers. This goes for any large numbers, including tweet ids. As far as I am concerned they can output everything in JSON as strings. Thoughts, Twitter? Dewald On Sep 24, 12:08 pm, jmathai wrote: > Agreed that the problem isn't Twitter's fault. But a basic feature > like cursor should work in a language as popular as PHP. Not so much > in principle but in practice. > > Has anyone tried PEAR's Services_JSON? I haven't tried nor looked at > the source. It's also slower than the native json_* functions but > that may or may not be an issue. > > On Sep 24, 6:52 am, Joseph Cheek wrote: > > > To be fair to Twitter, the problem lies in PHP's json_decode() function, > > not the twitter API. > > > Joseph Cheek > > jos...@cheek.com,www.cheek.com > > twitter:http://twitter.com/cheekdotcom > > > Dewald Pretorius wrote: > > > Chad, > > > > Shouldn't Twitter be providing an API that works for everyone? > > > > From what you said it sounds as if you're saying, "Tough. If you want > > > to consume the API with PHP, either run your stuff on a 64-bit > > > machine, or scrape the raw JSON output and make it so that it works > > > for you." > > > > That doesn't sound right. > > > > Dewald > > > > On Sep 24, 1:02 am, Chad Etzel wrote: > > > >> Hello, > > > >> As Joseph points out, PHP on a 64-bit system can handle these numbers. > > > >> If you really want this data as a string, you could write a regex in > > >> PHP to alter the json string to wrap the digits in quotes before > > >> sending it through json_decode(), but that would be a pretty gnarly > > >> kludge. > > > >> -Chad > > > >> On Wed, Sep 23, 2009 at 10:28 PM, Dewald Pretorius wrote: > > > >>> All that Twitter needs to do to solve this problem is to build the > > >>> JSON out with next_cursor and previous_cursor as string values. > > > >>> I.e., the JSON data should contain: > > > >>> "next_cursor":"12398712981212987","previous_cursor":"-12398712981212987" > > > >>> I don't know what it will do to Java apps, but for PHP apps it will > > >>> solve the problem. > > > >>> Dewald
[twitter-dev] Re: Will there be a Geolocation status method?
Try looking at: http://code.google.com/intl/fr-FR/apis/maps/documentation/geocoding/ Hope this helps. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Joseph Cheek Sent: Tuesday, September 22, 2009 11:00 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: Will there be a Geolocation status method? slightly off topic: does anyone know an easy (web?) method to translate location names (ie, "Atlanta, Georgia") to geodata coords and vice versa? thanks in advance Joseph Cheek jos...@cheek.com, www.cheek.com twitter: http://twitter.com/cheekdotcom Raffi Krikorian wrote: > > hi tom. > > if there is geo data, then the "near parameter" will be using that. > if not, then it will use the location in the user's profile. > > does that help? > >> Thanks. Am I correctly understanding that the near parameter uses the >> location of the users profile and will not use the new geolocation api >> lat/long data? >> >>> It is very unlikely that we would offer a publicly available method on >>> the streaming API that returned all geotagged statuses. It is much >>> more likely that we'll offer a parameter to the /1/statuses/filter >>> method that would be subject to the same limitations as the track >>> keyword. Such a feature is unscheduled. I wouldn't guess as to when >>> we'll get to such an implementation. >>> >>> In the mean time, the Search API offers the near: parameter. >>> >>> -John Kaluckihttp://twitter.com/jkalucki >>> Services, Twitter Inc. >>> >>>> I want to filter the firehouse to a subset of tweets that will have >>>> valid geodata (lat/long). >>> >>>>> hi tom. >>>>> what are you exactly asking? you can look at any of the timeline >>>>> methods -- >>>>> wherever there will be object, there will be geo >>>>> information if >>>>> there is geo information available. >>> >>>>> does that help? >>> >>>>>> Something like statuses/geolocation that returns public statuses >>>>>> with >>>>>> geolocation data? Thanks. > > -- > Raffi Krikorian > Twitter Platform Team > ra...@twitter.com | @raffi
[twitter-dev] Re: non json response
I agree with John that to achieve higher user visible reliability, API requests should be wrapped in a retry loop. However, PLEASE, PLEASE, PLEASE, do NOT use linear backoff, i.e., subsequent retries are delayed by an amount of time chosen uniformly at random up to the same maximum amount for each retry. This will lead to disasters for all API users as failed API requests, when retried, will tend to bunch up in ever increasing bunches, leading to a higher, not lower, failure rate. You should instead use exponential backoff, where the maximum amount of delay time increases for each retry. Queuing theory and experience indicate that the optimum factor used to increase the maximum delay for each retry should be 2.0. The earliest implementations of both Ethernet and TCP, and I'm sure other protocols, tried linear backoff and experienced this problem in spades. When the backoff was changed to exponential, the problems miraculously went away. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of John Kalucki Sent: Wednesday, September 16, 2009 12:56 To: Twitter Development Talk Subject: [twitter-dev] Re: non json response I've been following the internal dialog on tracking this issue down. Given what we know, I don't think there's anything that you can change to the request parameters to reduce the chances of this happening. >From a given client, the chances of this happening to a request are pretty close to random. Different clients, however, seem from the outside to operate differently, as they tend to routed through different infrastructure. There also may be differences in the quality of the code, especially around how errors are handled. If you want higher reliability, I'd suggest wrapping nearly all network API calls in a retry loop. If you get any sort of error: tcp, http, parser, etc. retry with linear backoff. -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Sep 16, 10:23 am, Naveen A wrote: > Is there a specific way we can construct our request to mitigate the > non-json response? I have used a few different twitter clients on the > same mobile device and some of them do not seem to be plagued with the > bad data like we are? Does including something in the header help get > us through whatever filter is returning the bad data? > > Maybe the Twitter cookies that are returned back on each request? > Currently, we don't pass them back on subsequent requests because they > shouldn't be necessary, but if it will make some of the bad JSON > responses go away, I'll spend the time to implement it.. > > These bad json responses have been a problem for over a month now and > while I realize it is a difficult problem to track down, the fact > remains that the API is not functioning correctly. > > A response from the twitter team would be greatly appreciated. > > On Sep 13, 6:01 am, Rudifa wrote: > > > I just had one non-json response, in the middle of about 10 requests > > made with curl -vvv (other responses were correct) > > > Below are 3 requests and the non-json response bracketted by 2 good > > responses which contain the response time and other logging data. > > > HTH > > Rudi > > > rudolf-farkass-macbook-pro:TwitterWeb rudifarkas$ curl -vvvhttp://twitter.com/users/show/rudifa.json > > * About to connect() to twitter.com port 80 (#0) > > * Trying 168.143.161.20... connected > > * Connected to twitter.com (168.143.161.20) port 80 (#0)> GET /users/show/rudifa.json HTTP/1.1 > > > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 > > > Host: twitter.com > > > Accept: */* > > > < HTTP/1.1 200 OK > > < Date: Sun, 13 Sep 2009 09:45:23 GMT > > < Server: hi > > < X-RateLimit-Limit: 150 > > < X-Transaction: 1252835123-2408-31139 > > < Status: 200 OK > > < ETag: "df090f6c8147e20ba7fe81315a66b9af" > > < Last-Modified: Sun, 13 Sep 2009 09:45:23 GMT > > < X-RateLimit-Remaining: 124 > > < Content-Type: application/json; charset=utf-8 > > < Pragma: no-cache > > < Content-Length: 1176 > > < Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, > > post-check=0 > > < Expires: Tue, 31 Mar 1981 05:00:00 GMT > > < X-Revision: a62881015b2c2fb6f795bf931bd56bd494f37254 > > < X-RateLimit-Reset: 1252836853 > > < Set-Cookie: lang=en; path=/ > > < Set-Cookie: > > _twitter_sess=BAh7CDoRdHJhbnNfcHJvbXB0MDoHaWQiJWU5OGQyZmU3NWVkY2RhZjhkYT k5% 250ANTBlNTA4OTk0MzhhIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFz > > %250AaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA
[twitter-dev] Re: Comments for the group and Twitter staff
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@ *
[twitter-dev] Re: Default profile pics
Factoid, FWIW: so far, I've found 7: http://s.twimg.com/a/1252980779/images/default_profile_x_normal.png where 0<=x<=6. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of timwhitlock Sent: Tuesday, September 15, 2009 06:39 To: Twitter Development Talk Subject: [twitter-dev] Default profile pics I notice today that Twitter has created a new default profile pic; e.g: http://s.twimg.com/a/1252980779/images/default_profile_1_normal.png Great. That's broken some of my algorithms on Twitblock.org. (identifying re-used images) I can fix that. I'll just add the new MD5 to my app config. But, wait. Did I spot some different colours? Yes, that example is only one; e.g.2: http://s.twimg.com/a/1252980779/images/default_profile_2_normal.png a. Can Twitter tell use how many there are of these? b. How about a user object property "profile_image_default" (true| false) ? c. How about Twitter start notifying the developer community of changes?
[twitter-dev] Re: Errornous link - Bracket problem with bit.ly
I completely agree with the sentiment as stated, but have a question. Does the URL shortening happen only for tweets entered at twitter.com? Or does it also happen for tweets created via the API? The former is a twitter UI issue, and if they want to shorten tweets, well, that's their business. But shortening URLs in tweets created via the API is *MY* business as a user of the API, and, IMHO, none of theirs. If I and / or my user want a URL shortened, we'll do it. And if I or my user *DON'T* want it shortened, then the API should not do it. If in fact URL shortening is possible via the API, then there should at least be an option to suppress it. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of JDG Sent: Thursday, September 10, 2009 16:19 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: Errornous link - Bracket problem with bit.ly Yet another reason Twitter should NOT be bit.ly encoding URLs that do not cause tweets to go > 140 chars. (or at all for that matter, leave that up to the users) On Thu, Sep 10, 2009 at 13:42, Matthew Terenzio wrote: Yes, you need to ask twitter to fix that. They are using our api, but obviously, they are encoding the ")" after the .jpg. Thanks for letting us know, but yes, this is a twitter issue. Good luck with that. Since it is acceptable to have the unencoded ) character in a URL, I don't know how they might interpret that it does not belong. They can make a good guess at best. -- Internets. Serious business.
[twitter-dev] Re: Mobile oAuth
OAuth is great, in certain circumstances. In others, it's not so great. Circumstances for which it is great include: - consumer web sites; and - consumer client applications that have access to a reasonable browser on the client device in both cases with the qualification that the authorization pages of the service provider are in a language (e.g., English, Japanese, etc.) that is the same as that used by the consumer. In these circumstances, OAuth as defined by the specifications and implemented by twitter works very well. Circumstances for which it is not so great include: - consumer client applications that do not have access to a reasonable browser on the client device; and - consumer client applications and web sites that are in languages for which service authorization pages in those languages are not available. In these circumstances, OAuth as defined by the specifications and implemented by twitter does not work so well. Currently, in circumstances where OAuth does not work very well, twitter client applications and web-sites can resort to Basic Authentication. The drawbacks to this are obvious: - the user must give their twitter password to the client; - at some point twitter will no longer support Basic Authentication; and - the source of tweets created by these clients is "API" rather than the client's name. Pooh pooh the last drawback if you will, but to some it is important. Now, the fact of the matter is that some users are perfectly comfortable in giving their twitter passwords to client applications and web-sites, even where those clients support OAuth. I don't think these users should be penalized and forced to use OAuth if'n and when'n twitter drops support for Basic Authentication. And if'n and when'n twitter drops support for Basic Authentication, client applications and web-sites that now only support Basic Authentication will be forced to support OAuth. Myself, I don't think that's an unreasonable requirement, but others may differ. And I don't think these creators should have to forgo having their client's name as the source of tweets their clients create, now or ever, just because their users chose to trust them to use Basic Authentication. So I propose the following enhancement to twitter's OAuth implementation: Allow a userID and password to be included as optional parameters of an oauth/access_token request. If supplied and authentic, they would cause a valid access token to be returned without the user having visited the authorize URL and approved the access. Alternately, the userID and password could be optional on an oauth/request_token request, in which case, if supplied and authentic, the request would return a valid access token, rather than a request token, again without the user having visited the authorize URL and approved the access. The advantage to this alternative is it reduces by one the number of API calls needed. I believe either of these alternatives is a viable solution for the circumstances where the existing OAuth implementation does not work so great. Comments expected and welcome. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of twittme_mobi Sent: Friday, September 04, 2009 08:39 To: Twitter Development Talk Subject: [twitter-dev] Re: Mobile oAuth I am also interested in mobile oath solution. twitter guys should think of something before deprecating basic auth On Aug 20, 8:01 am, Cameron Kaiser wrote: > > I have a mobile based twitter client in the field and have implemented > > oAuth for this client. Some of the devices are either very low memory > > or have primitive browsers that dont support the rendering of the > > 'allow' / 'deny' access page (http://twitter.com/oauth/authorize). I > > have tried the obvioushttp://m.twitter.com/oauth/authorizebut this > > seems to serve the same standard webage. > > > So Im looking for nat previous info or plans of a lightweight > > implementation of oAuth access page for twitter. > > I'm also particularly interested in such a page, especially one a text > browser could access such as Lynx or w3m. > > -- > personal:http://www.cameronkaiser.com/-- > Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com > -- Adore, v.: To venerate expectantly. -- Ambrose Bierce --
[twitter-dev] Re: New ReTweet API
In http://groups.google.com/group/twitter-api-announce/browse_thread/thread /8540da9d7d64c46 Marcel, on behalf of twitter, announced to availability of the statuses/home_timeline method. This is good news! It will allow us to start development of retweet support in our client applications / web-sites, and do backward compatibility testing. Would it be possible, if it has not already been done, for twitter to create a couple of accounts that include some retweets so we can also do forward compatibility testing? It doesn't have to be much, just a half-dozen or so nonsense status updates in each account, some retweeted, some not. When you do this, please be sure to include an example of a status update that is retweeted by more than one other account. I, and others, still have questions, so far unanswered, about what the results will look like in this case, and other similar cases. Thanks in advance, Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of jim.renkel Sent: Thursday, September 03, 2009 13:32 To: Twitter Development Talk Subject: [twitter-dev] Re: New ReTweet API I asked this, and similar but more detailed questions, in my Aug 18, 7:35 pm post to this thread: http://groups.google.com/group/twitter-development-talk/browse_thread/th read/1e07e332ec3d449d/2d10a6a22e55133e?lnk=gst&q=ReTweet+API#2d10a6a22e5 5133e but, unfortunately, have not yet received an answer, at least none that I can find. Could someone from twitter (Marcel Molina?) please address these issues? I think they are pretty important. I need to know the answers to be able to design support for retweets in my site (http://twxlate.com). I would hope I wouldn't have to resort to experimentation once this feature is deployed at twitter.com to get answers to what I think are pretty fundamental questions. Thanks in advance, Jim Renkel On Aug 14, 1:35 pm, Houshang Nayeb wrote: > I have the following question: > > If one of my tweets is retweeted multiple times, what will be the > return value of retweets_of_me.format ? Will it be one record with > multiple sections? > > If yes, will there be a count for the number of times it has been > retweeted? > If no, then what happens? > > Thanks!
[twitter-dev] Re: [ANN] statuses/home_timeline resource now available (though it doesn't include retweets yet)
Marcel, This is good news! It will allow us to start development of retweet support in our client applications / web-sites, and do backward compatibility testing. Would it be possible, if it has not already been done, for twitter to create a couple of accounts that include some retweets so we can also do forward compatibility testing? It doesn't have to be much, just a half-dozen or so nonsense status updates in each account, some retweeted, some not. When you do this, please be sure to include an example of a status update that is retweeted by more than one other account. I, and others, still have questions, so far unanswered, about what the results will look like in this case, and other similar cases. Thanks in advance, Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Marcel Molina Sent: Wednesday, September 02, 2009 18:23 To: twitter-development-talk@googlegroups.com; twitter-api-annou...@googlegroups.com Subject: [twitter-dev] [ANN] statuses/home_timeline resource now available (though it doesn't include retweets yet) We mentioned in our early preview email about the retweet API (http://groups.google.com/group/twitter-api-announce/browse_thread/threa d/1e07e332ec3d449d) that the statuses/friends_timeline resource wasn't going to include retweets for backwards compatibility so we don't break clients that aren't planning to add retweet support. The upgrade path is entirely opt-in. To that end we're adding a statuses/home_timeline resource that is in all ways identical to statuses/friends_timeline except the home_timeline resource *will* include retweets as demonstrated in the example payload in the documentation at http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-home_time line. The statuses/home_timeline resource is now available though it won't include any retweets until the retweeting feature is fully launched. To be clear, until the full retweet launch, statuses/home_timeline will be 100% identical to statuses/friends_timeline and will *not* include retweets. We wanted to make the resource available early though so that clients who will be incorporating retweets into their timelines can update the resource that they reference and have requests succeed. When the full retweet launch happens, retweets will start to appear in statuses/home_timeline as per the documentation. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Private user's 'following' information: why am I denied access via API but can get through Twitter.com?
Hmm! I'm not sure what the problem is you're having, but my site has no problem seeing her followers. You can see this at: http://twxlate.com/?a=fllwrs&u=just_me_hi Hope this helps. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Tweet Thief Sent: Thursday, September 03, 2009 02:37 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Private user's 'following' information: why am I denied access via API but can get through Twitter.com? 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 to http://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_hi&user_b=twee tthief" Results in: HTTP/1.1 403 Forbidden Status: 403 Forbidden (irrelevant headers edited) /friendships/exists.xml?user_a=just_me_hi&user_b=tweetthief You do not have permission to retrieve following status for both specified users. 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: if you will be using the Geolocation API ...
Raffi, Is it only the account/verify_credentials method that will return the sub-element in the element, or all methods that return a element? While having only account/verify_credentials return it is better than nothing, I would hope that all methods that return a element would include a sub-element. For consistency, if nothing else. With the issues associated with account/verify_credentials requests and the DOS attack, I have been avoiding using the method: Basic Authentication credentials can be, and in fact are, verified with any and every authenticated request; OAuth credentials (access token and token secret) are by their nature pre-authenticated, and are, again, re-verified with each and every use. So this may require me to issue an account/verify_credentials request where I would otherwise not have to do so, just to get the flag. I can, and will if necessary, do that, but would prefer not to. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Raffi Krikorian Sent: Wednesday, September 02, 2009 18:01 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: if you will be using the Geolocation API ... hi jim. yup! http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0verif y_credentials > Raffi, > > Another question came up as I was thinking about support for this in > my web-site (http://twxlate.com): > > Will the elements returned in the responses to API requests > include information that indicates whether or not the user has opted- > in to geo-coding of their tweets? > > I would like to see this right from the get go so that client web- > sites / applications know whether or not to prompt their users for > location information to be geo-coded with a tweet that is being > created. If this isn't there, I think there will be unnecessary > confusion and possibly wrong actions taken on behalf of the user. > > Please seriously consider this for inclusion in the initial > deployment, if it is not already there. > > Thanks in advance. > > Comments welcome and expected. > > Jim Renkel > > On Sep 1, 6:08 pm, Raffi Krikorian wrote: >> hey jim. >> >> >> >>> 1. "the user.location is a completely separate entity (for now)" >>> implies >>> that maybe sometime in the future it may be used, e.g., to provide a >>> default geo-coded location for a tweet. I would suggest that if the >>> user's profile location if ever geo-coded, that geo-code should be >>> added >>> to the objects returned by API calls, at least the users/show >>> method. Users will want to know what may be, e.g., added to their >>> tweets >>> without having to generate a test tweet to find out. >> >>> 2. Having the user's profile location geo-coded and returned in API >>> calls would be very useful now. Yeh, twitter client web-sites / >>> applications can do it for themselves (Mine certainly will if >>> twitter >>> doesn't do it.), but may come up with different / inconsistent >>> results. >>> And, trust me, it ain't as easy to get good results as it might >>> first >>> appear. To maximize use and consistency, it would be great if >>> twitter >>> did the geo-coding and supplied it to everyone. >> >> these are both great ideas. right now, the geolocation API is really >> focused on tweet-level information -- but we're actively thinking >> about what's next. >> >>> 3. Will twitter client web-sites / applications be able to turn the >>> geo-location feature on for their users, or do the users have to >>> go to >>> twitter.com with a browser to do this? My concern here is that >>> twitter.com only supports two languages (English and Japanese) for >>> its >>> UI, where my site (http://twxlate.com) supports these and over 40 >>> more. >>> Unless the user is fluent in English or Japanese, they won't be able >>> to >>> turn it on. I've already run into similar problems as I'm rolling >>> out >>> test versions of OAuth support. >> >> unfortunately not. as we're pretty sensitive to our user's privacy, >> for now, a user will have to go to twitter.com with a browser to turn >> on the setting (remember, by default it is off). if you have any >> suggestions on how to make this user interaction better in the >> future, >> i would be eager to hear them! >> >>> As I've written some pretty spiffy geo-coding applications for other >>> purposes, I plan on doing some pretty spiffy geo-coding stuff with >>> twxlate.com. But it needs to be usable, or users won't use it >>> and / or >>> may be annoyed by it. I would hate for that to happen to what >>> promises >>> to be a really neat feature. >> >> cool! well - i hope what we're doing is usable! if not, just keep >> blasting me about it. threads like these on the mailing list are >> awesome. >> >> -- >> Raffi Krikorian >> Twitter Platform Team >> ra...@twitter.com | @raffi -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] Re: Twitter IP Whitelisting
I don't think white-listing is going to help with a latency problem. It only gets ya way more API GET requests per hour. Latency issues are probably due to twitter infrastructure problems, i.e., delays in the back-end DB servers posting updates from the front-end UI servers. We've been seeing this recently with follow / un-follow requests. Your issue may be another symptom of the same root problem. Hope this helps. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Andy Pirate Sent: Wednesday, September 02, 2009 01:28 To: Twitter Development Talk Cc: ma...@pwned.com Subject: [twitter-dev] Twitter IP Whitelisting So here's the deal. We've had the Twitter API integrated into Pwned.com for many months now. One problem we keep running into is that it updates our members Twitter WAY later. For example, it says so and so is playing on-line, but we processed that request hours ago and then it finally shows up on their feed. I have requested whitelisting before, but they claimed it was approved and I don't think that it is. We've had to severely limit our integration with Twitter because of this reason. Any help would be greatly appreciated. Thanks Andy
[twitter-dev] Re: if you will be using the Geolocation API ...
Raffi, Most Excellent! But a couple of more questions / comments, of course 1. "the user.location is a completely separate entity (for now)" implies that maybe sometime in the future it may be used, e.g., to provide a default geo-coded location for a tweet. I would suggest that if the user's profile location if ever geo-coded, that geo-code should be added to the objects returned by API calls, at least the users/show method. Users will want to know what may be, e.g., added to their tweets without having to generate a test tweet to find out. 2. Having the user's profile location geo-coded and returned in API calls would be very useful now. Yeh, twitter client web-sites / applications can do it for themselves (Mine certainly will if twitter doesn't do it.), but may come up with different / inconsistent results. And, trust me, it ain't as easy to get good results as it might first appear. To maximize use and consistency, it would be great if twitter did the geo-coding and supplied it to everyone. 3. Will twitter client web-sites / applications be able to turn the geo-location feature on for their users, or do the users have to go to twitter.com with a browser to do this? My concern here is that twitter.com only supports two languages (English and Japanese) for its UI, where my site (http://twxlate.com) supports these and over 40 more. Unless the user is fluent in English or Japanese, they won't be able to turn it on. I've already run into similar problems as I'm rolling out test versions of OAuth support. As I've written some pretty spiffy geo-coding applications for other purposes, I plan on doing some pretty spiffy geo-coding stuff with twxlate.com. But it needs to be usable, or users won't use it and / or may be annoyed by it. I would hate for that to happen to what promises to be a really neat feature. Thanks in advance, Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Raffi Krikorian Sent: Tuesday, September 01, 2009 17:20 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: if you will be using the Geolocation API ... > My understanding is that all tweets will contain geo-location > information: if the information was supplied when the tweet was > created, > that will be used; if no information was supplied, then the "default" > location from the user's profile will be used. actually - if there is no data passed in via the Geolocation API (the "lat" and "long" parameters on the update), then the geo object in the response will be empty. the user.location is a completely separate entity (for now). > 1. What if the location in a user's profile can't be geo-coded and no > geo-location is provided when creating a tweet? I would hope that no > geo-location is then provided in the tweet. if a valid latitude and longitude is not provided with the tweet, then no geo data will be returned with the tweet. the user, however, will still have his/her "location" as set in his/her settings page. > 2. If it is possible to not have a geo-location attached to a tweet, > e.g., because of the circumstances above, then I suggest that there > be a > parameter on the status/create method that suppresses copying the > default geo-location to the tweet. > > In fact it should probably be the other way around, i.e., *DO* include > the default location, for security reasons such as those mentioned by > Lepton. I understand this will probably (significantly) reduce the > number of tweets that are geo-coded, but I think this is appropriate > given the sensitivity of the geo-location: I think users should have > to > "opt-in" on a tweet by tweet basis to have their tweets geo-located. by default, every twitter account will have access geolocation API turned _off_. moreover, the only way to turn it on is for the user to log into twitter's web site, go to his or her's settings page, and then toggle access on. if a user (or an application on behalf of the user) attempts to send geolocated information up to twitter along with the tweet, and geolocation is turned off, then the tweet will go through, but the geolocated information will be dropped and not stored. hope that helps! -- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
[twitter-dev] Re: if you will be using the Geolocation API ...
My understanding is that all tweets will contain geo-location
information: if the information was supplied when the tweet was created,
that will be used; if no information was supplied, then the "default"
location from the user's profile will be used.
I, too, have several comments and questions.
1. What if the location in a user's profile can't be geo-coded and no
geo-location is provided when creating a tweet? I would hope that no
geo-location is then provided in the tweet.
2. If it is possible to not have a geo-location attached to a tweet,
e.g., because of the circumstances above, then I suggest that there be a
parameter on the status/create method that suppresses copying the
default geo-location to the tweet.
In fact it should probably be the other way around, i.e., *DO* include
the default location, for security reasons such as those mentioned by
Lepton. I understand this will probably (significantly) reduce the
number of tweets that are geo-coded, but I think this is appropriate
given the sensitivity of the geo-location: I think users should have to
"opt-in" on a tweet by tweet basis to have their tweets geo-located.
3. Will twitter be going back and geo-coding the locations given in
existing twitter accounts? If so, will it be all at once as a batch, or
the first time an old account is used to create a tweet with a
geo-location, or something else?
4. Presumably an update of an account's location will cause that new
location to be geo-coded. Will there be a delay in this, as we see with
other updates to information in twitter, or will it be instantaneous,
i.e., will the next tweet created for an account whose location is
updated be guaranteed to contain the new location's geo-code?
5. I like the idea of levels of disclosure of geo-location information,
but I dont think this can be practically implemented.
Jim Renkel
-Original Message-
From: twitter-development-talk@googlegroups.com
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Lepton
Sent: Tuesday, September 01, 2009 08:50
To: Twitter Development Talk
Subject: [twitter-dev] Re: if you will be using the Geolocation API ...
My iPhone app ( http://myallo.com/hotlist currently waiting for Apple
approval to go into the App Store) periodically wants to tell Twitter
the user's location. If the user is in motion, and the app is open, as
often as every 5 minutes. But it doesn't want to tweet it ("I'm here",
"Now I'm here", "Now I'm here"). That would be... bad. So I'll still
want to put it in the user profile.
There are two other things. A question and a suggestion:
Will every tweet include a location? My app is, most of the time, only
interested in seeing a friend's location and most recent last tweet.
It would be great if I could do this in one call (and greater if I
could ask about several friends at once). If a user is only putting a
location in the profile, will this location be sent along with each
tweet?
Locations have no security. It's the first, second, and third thing
every single person wants to know about my app: "Who can see me, who
can I see, what about stalkers?" PEople are very security oriented
when it comes to location, rightly so. Currently with Twitter I work
around this by having the app optionally post approximate coordinates.
But a level of security would be great, and I think necessary to make
geolocation successful and popular. For example take a look at
brightkite.com. They have three levels of people: "The public",
friends, and trusted friends. For each of those, you can set See my
exact location, see only the city I'm in, or see nothing. That's
really useful. For Twitter, it might be relatively easy to add a flag
saying Only people I follow can see my location, and/or only followers
can see my location. And/or you could have a list of users who could
see my location.
On Aug 31, 11:44 am, Raffi Krikorian wrote:
> part of our hopes when we designed the geolocation API is that people
> can start putting their profile location (user.location) back to
> something "useful" (e.g. mine could say "san francisco, ca") because
> the specific location can be added as metadata to each tweet.
>
> what we're hoping for is that the user.location becomes something that
> describes the user, and not the tweet. the geolocation API is for
> describing the tweet.
> do you have any suggestions as to what sorts of gotcha's we should
> look out for?
[twitter-dev] Re: api user rate limit from different ip addresses
If the API requests come from your server when users view your page, then, yes, your users will be collectively limited to 150 unauthenticated GET requests per hour, unless your site is white-listed. If your site was white-listed, it would get 20,000 unauthenticated GET requests per hour. You also authenticate the requests using multiple accounts and get 150 (or 20,000, if white-listed) API GET requests per hour for each account used for authentication. If the API requests come from your users' computers, then each will get 150 API GET requests per hour. Hope this helps. Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of NATO24 Sent: Tuesday, September 01, 2009 12:12 To: Twitter Development Talk Subject: [twitter-dev] api user rate limit from different ip addresses Sorry, I couldn't find the answer in any previous thread even though there are hundreds. Scenario: I create a jQuery plugin that pulls in "my" status updates (not authenticated using REST). Each person viewing my page (from different ip addresses) hits the API once every hour. Question: Does this mean that only 150 people can simultaniously view that page without hitting the rate limit? Will it be restricted by "my" account rather than by ip? Thanks, Nathan
[twitter-dev] Re: Getting screen name from user id without rate limit
Would 20,000 API GET requests per hour be sufficient for your application? If you are checking for spammers rather than being one, I would think twitter would gladly white-list you! Jim Renkel -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Twixcel Sent: Friday, August 28, 2009 23:55 To: Twitter Development Talk Subject: [twitter-dev] Getting screen name from user id without rate limit I'm trying to develop a twitter app that checks if someone is a spammer. I have the userid, but to get the screenname I have to call http://twitter.com/users/show.xml?id= which causes a limit request. Once I have the screen name I could get the data I need without a limit request. Does anyone know a way to get the screen name from a user Id without incurring a rate limit charge?
