Re: [twitter-dev] how to get twitter user's email address
you can't, and that's by design for privacy reasons. On Mon, Dec 20, 2010 at 9:58 AM, Zhou Tong tongzhou...@gmail.com wrote: I don't find any api can get friends email address. it's very important to my application. help me ,thanks -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
Re: [twitter-dev] I'm sure you guys know this, but ...
I would question the fully recovered if I look at the still unrealistic values returned for number of tweets per user... On Tue, Jun 15, 2010 at 3:27 PM, Taylor Singletary taylorsinglet...@twitter.com wrote: Twitter had quite a night. http://status.twitter.com/post/699623494/site-availability-issues-due-to-failed-enhancement-of On Mon, Jun 14, 2010 at 11:39 PM, M. Edward (Ed) Borasky zn...@borasky-research.net wrote: I'm experiencing multiple chaotic symptoms on the main web application. 1. I post a tweet. I get Internal System Error but the tweet posts. 2. I go to my home page http://twitter.com/znmeb and it's totally blank. 3. I see multiple copies of tweets and other people see multiple copies of mine. 4. Under the tweet box, under the location it says, Share your first tweet with the world 5. The retweet button was gone, but now it's back. This is in addition to the fail whales, which seem to have gone away. It looks to me like code is being switched in and out of operation in a somewhat unplanned manner. Ordinary folks are starting to ask me WTF and I have no clue. The good news is that the places selection in the web application is giving me a bigger list of possible places. I'm trying now to see what's being posted in the tweets.
Re: [twitter-dev] Re: countdown to OAuth / basic auth removal / OAuthcalypse
Did you whitelist your app for xAuth?
On Apr 25, 2010 1:22 PM, Craig Hockenberry craig.hockenbe...@gmail.com
wrote:
Hi Raffi!
Is there a delay/verification after a new app is created? I just
created a new app and am seeing problems getting the OAuth token with
a xAuth HTTP request that looks like this:
xAuth consumer key = N3fq77IdBT4qfglbcb4njg, consumer secret =
REDACTED
xAuth URL = https://api.twitter.com/oauth/access_token
xAuth HTTP method = POST, shouldHandleCookies = NO, cachePolicy =
NSURLRequestReloadIgnoringCacheData
xAuth HTTP headers = {
Content-Length = 78;
Content-Type = application/x-www-form-urlencoded;
}
xAuth HTTP body =
x_auth_mode=client_authx_auth_username=REDACTEDx_auth_password=REDACTED
I get back a status code of 0 and a response of Failed to validate
oauth signature and token.
For an older application with different consumer information (key =
5CAYV1DR5uwhVRJDBrepw) but the same username and password), I get back
a code of 200 and an empty response.
If there is indeed a delay for this information to propagate, you need
to let people know...
-ch
On Apr 24, 8:40 am, Raffi Krikorian ra...@twitter.com wrote:
hi all.
you're going to be hearing a lot from me over the next 9 weeks. our plan
is
to turn...
Twitter Platform Teamhttp://twitter.com/raffi
--
Subscription settings:http://groups.google
--
Subscription settings:
http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: [twitter-dev] Re: Twitter buying Tweetie
There are more colors (or shades of grey) in my world than just black and white... On Sat, Apr 10, 2010 at 9:21 PM, Dewald Pretorius dpr...@gmail.com wrote: If you're an entrpreneur with strong ethical standards, then never ever accept investment capital. Investors could not give a shit about your ethical qualms or objections, and they are most certainly not going to accept a lower exit because of them If you don't play ball, they simply replace you with someone who will. Whenever I read about an entrepreneur joyously announcing that he got such-and-such amount of venture capital, I think to myself, Dude (or dudess), I hope you realize that you have just sold your soul and handed over control of your destiny to someone else. On Apr 10, 4:23 pm, M. Edward (Ed) Borasky zn...@comcast.net wrote: On 04/10/2010 11:45 AM, Arnaud Meunier wrote: We shouldn’t “fill holes” anymore, Wilson said. The thing is Twitter has deliberately kept a lot of holes opened, encouraging us to fill them (and lots of applications have been doing it with innovation, by the way). I don't know that it's deliberate - a lot of it has to do with the growth dynamics of the Twitter ecosystem in particular and social media in general. I've been on Twitter since early 2007 - in fact, @znmeb predates @twitter. ;-) It was an exclusive club and something that relatively few people knew about. I used Twitter rarely until the financial crisis of fall 2008. Maybe it's a coincidence, but I don't think it is, that the main growth spurt in Twitter user IDs (http://meb.tw/b6WCzv) began towards the end of 2008 after the election of Barack Obama brought national media attention to Twitter. That was when I discovered the Portland Twitter community and began using Twitter in earnest. Wilson is a venture capitalist - he takes *calculated* risks. He blogs to help his investments pay off, so his clients make money, thereby attracting more money to his firm. He is on the board of *directors* of Twitter. Directors *direct*. They may also advise, but I'm not privy to the exact mix of direction and advice he provides. In any event, he is no doubt keenly aware of the dynamics of the ecosystem. His advice, as expressed in his blog post, is worth consideration. Now we’re supposed to dig, create new holes, and fill them. Okay! There are a lot of ideas to have around Twitter, lots of new holes to dig. There are also numerous open positions at Twitter. Some of the holes Twitter wants to fill appear to be revealed in the job descriptions. ;-) But the question is still the same: What will be left up to the ecosystem and what will be created on the platform? Because of the growth dynamics in social media, I don't think anyone, in the Twitter ecosystem or outside of it, can answer that. There are some (fairly) simple models of such things, but human behavior is hard to predict and bloggers and pundits and VCs can only speculate, collect as many hard numbers as possible and build models with them. I think I'm not the only one here to fear that Twitter itself begins to compete with the applications I created (or I plan to create). Yes, it's fun to dig holes and to fill them. But it also takes time and money, and it's like the game was going to be much more risky than it used to be. Again, that's not necessarily certain as long as there are uncertainties in Twitter usage patterns and in the competitive landscape of social media. Wilson's blog post is, I believe, a pretty good overview of the current state of the ecosystem, but how it evolves is not independent of the competition and the consumer. And neither is the allocation of resources between the Twitter entity and third party developers, large and small. -- M. Edward (Ed) Boraskyhttp:// borasky-research.net/about-smartznmeb/@znmeb A mathematician is a device for turning coffee into theorems. ~ Paul Erdős -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Introduce yourself!
I'm Marco Kaiser (@marco), started playing with the API in Summer 2007 and developed AIR-based twhirl back then. It was acquired by Seesmic almost two years ago now, and I joined the company, too. Did a couple more Twitter desktop apps since then... :) I am based in Germany, and I also act as a moderator on this list. I'll be at Chirp. Cheers, Marco On Sat, Feb 20, 2010 at 10:17 PM, Scott Wilcox sc...@tig.gr wrote: Hi, I'm Scott Wilcox (@dordotky). I'm a freelance developer and currently run and maintain the http://tweekly.fm and http://laststat.us services. I developer mostly in PHP over the majority of my projects but plan to switch to either Ruby or Python this year. I'm also an iPhone developer and plan to release a few apps this year. I use both the REST API and Streaming API regularly and agree with the comments on standardising the errors across the platform (the user_timeline as mention by Marc is a particular pet hate). I've also been doing some research in to awareless of embedded EXIF data in images that are posted to Twitter via services such as twitpic.com. I'll be publishing these finds towards the end of the month. I sadly won't be attending Chirp due to it being too far to travel from England and not enough funds to do so :( Hopefully one of you will create a webcast for me to watch! Scott.
Re: [twitter-dev] Re: Search API: new HTTP response code 420 for rate limiting starting 1/18/2010
yeah, doesn't make much sense to have two different codes indicating that the limit is exceeded... 2009/12/23 DustyReagan dustyrea...@gmail.com Will you be changing the REST API error code to match the Search API? RE: 420 = rate limit exceeded. On Dec 22, 4:44 pm, Wilhelm Bierbaum wilh...@twitter.com wrote: We're changing the response code sent back by the Search API when the rate limit has been exceeded. At present, it is impossible to distinguish rate limit responses from other error conditions in responses from the Search API -- this is what we're trying to fix. Starting Monday, January 18th, 2010 the Search API will respond with error code 420 in the event that the number of requests you have made exceeds the quota afforded by your assigned rate limit. Please update your response your response handler to accommodate this new behavior. Apologies for the false start last time this change was announced. If you have any questions, please feel free to post them on twitter-development-talk. Thanks!
Re: [twitter-dev] Retweet API methods returning 404
They are working for me, both on the API and the website - are they back for you, too? Or are just some users affected? Marco 2009/12/17 Abraham Williams 4bra...@gmail.com Retweets are disabled on twitter.com. I don't see any status message announcing it though. Abraham On Thu, Dec 17, 2009 at 06:05, Dimebrain daniel.cre...@gmail.com wrote: The following retweet methods have started returning 404's in our unit testes: http://api.twitter.com/1/statuses/retweeted_by_me.json http://api.twitter.com/1/statuses/retweeted_to_me.json http://api.twitter.com/1/statuses/retweets_of_me.json http://api.twitter.com/1/statuses/retweets/[any_status_id].jsonhttp://api.twitter.com/1/statuses/retweets/%5Bany_status_id%5D.json Anyone else having this issue, or know what happened to these API methods? -- Abraham Williams | Awesome Lists | http://bit.ly/sprout608 Project | Intersect | http://intersect.labs.poseurtech.com Hacker | http://abrah.am | http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private. Sent from Madison, WI, United States
Re: [twitter-dev] Retweet API methods returning 404
okay - just noticed that they work on my whitelisted account, but not on a regular account. so yeah - looks as if RTs are down right now in general. Marco 2009/12/17 Marco Kaiser kaiser.ma...@gmail.com They are working for me, both on the API and the website - are they back for you, too? Or are just some users affected? Marco 2009/12/17 Abraham Williams 4bra...@gmail.com Retweets are disabled on twitter.com. I don't see any status message announcing it though. Abraham On Thu, Dec 17, 2009 at 06:05, Dimebrain daniel.cre...@gmail.com wrote: The following retweet methods have started returning 404's in our unit testes: http://api.twitter.com/1/statuses/retweeted_by_me.json http://api.twitter.com/1/statuses/retweeted_to_me.json http://api.twitter.com/1/statuses/retweets_of_me.json http://api.twitter.com/1/statuses/retweets/[any_status_id].jsonhttp://api.twitter.com/1/statuses/retweets/%5Bany_status_id%5D.json Anyone else having this issue, or know what happened to these API methods? -- Abraham Williams | Awesome Lists | http://bit.ly/sprout608 Project | Intersect | http://intersect.labs.poseurtech.com Hacker | http://abrah.am | http://twitter.com/abraham This email is: [ ] shareable [x] ask first [ ] private. Sent from Madison, WI, United States
[twitter-dev] Re: Lists API
thank you :) 2009/11/2 Marcel Molina mar...@twitter.com You may (until further notice) ;-) On Mon, Nov 2, 2009 at 10:12 AM, kaiser.ma...@gmail.com wrote: Can I translate that into 'the current URL to get a list using the slug will not be deprecated'? Marco -Original Message- From: Marcel Molina mar...@twitter.com Date: Mon, 2 Nov 2009 10:05:03 To: twitter-development-talk@googlegroups.com Subject: [twitter-dev] Re: Lists API It's available to all developers and has been since last Thursday. There are still some tweaks to be made but everything that works now should continue to be supported along side the changes and additions that will be introduced. On Mon, Nov 2, 2009 at 9:48 AM, Michael Steuer mste...@gmail.com wrote: With all the discussions on this mailing list about the Lists API, can someone please confirm, is the API now available to all developers or all of you in some sort of preferred position? Thanks, Michael. -- Marcel Molina Twitter Platform Team http://twitter.com/noradio -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Lists Prediction - So Set Rules And Prepare For It Now
Whom are you addressing - twitter or devs? or both? Marco 2009/10/30 Dewald Pretorius dpr...@gmail.com Just like the number of followers on Twitter has become a status symbol and a commodity, the number of lists you are on is also going to become a status symbol and commodity. You can expect services to very soon show up that will have all kinds of schemes to get someone on as many lists as possible. Paid, reciprocation, etc, etc. So, better set clear rules and limits right now, before it becomes a fire that you have to put out. Dewald
[twitter-dev] Re: user+password
As lists are available to 100% of users now, any unprotected (i.e., non-private) list resource doesn't seem to require auth anymore. Marco 2009/10/30 Abava dnam...@gmail.com and how to read list memebers (just id's) without credential? How to read list names for the particularly user without credential? Twitter API (draft for lists) requires authentication here. E.g. with this draft JSONP for lists is practically useless - how to pass username/password there without exposing them clearly in the javascript code. On Oct 28, 10:25 pm, ryan alford ryanalford...@gmail.com wrote: You are not required. I just used this API method without credentials. http://twitter.com/statuses/user_timeline/[InsertScreenNameHere].xmlhttp://twitter.com/statuses/user_timeline/%5BInsertScreenNameHere%5D.xml No credentials needed. Some API methods do required you to be authenticated, but some do not. You can view the methods athttp:// apiwiki.twitter.com/Twitter-API-Documentation and it will tell you if you have to be authenticated to do the method. Ryan On Wed, Oct 28, 2009 at 3:17 PM, Abava dnam...@gmail.com wrote: and why do we need user name+password just for reading something from the public list? E.g. just read members id's, read statuses etc. Why it is password protected?
[twitter-dev] Re: Find username/screenname through email addresses
No Marco 2009/10/27 dhaval dhaval.parik...@gmail.com Hey all Is it possible to find the screen name of a twitter user from an email address? Say suppose an email address is a...@abc.com then what is the corresponding screen name of the user with that email id if there exists a registered user with that email. Please let me know if there is any way to find that out. Thanks
[twitter-dev] Re: Checking if a user exists by email
No one accused you to be a spammer, and there are definitely very useful scenarios for such a functionality. But, and that's the key point, there a many many more scenarios in which it could be abused by spammers... Marco 2009/10/20 HAR Devel harsocialme...@gmail.com I can see how this might look like a spammer's request, but it can be used for legitimate purposes. Thanks for the info though. On Oct 15, 9:06 am, Andrew Badera and...@badera.us wrote: Haven't you heard about the allegedly spammer-hostile Address Book API that's coming soon? ∞ 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 Thu, Oct 15, 2009 at 10:00 AM, Duane Roelands duane.roela...@gmail.com wrote: ...and there never ever should be. On Oct 14, 4:55 pm, JDG ghil...@gmail.com wrote: no. On Wed, Oct 14, 2009 at 09:50, HAR HAR harsocialme...@gmail.com wrote: There was a post on this group called API Method for checking if a user exists? a while ago. The method for checking if a user exist described there no longer works. Is there a way for me to use the API to verify if an email address is associated with a twitter account? Thanks. -- Internets. Serious business.
[twitter-dev] Re: Nero 9 - FULL Version - [Precracked] 51MB ONLY!
you probably wouldn't believe how much spam we delete before it actually hits the list... 2009/10/19 Dave Briccetti da...@davebsoft.com Google group admins can actually DELETE spam, too, which would be nice.
[twitter-dev] Re: Download Avira 2010 an key 2014
uhm... should I ban @al3x now from the group?! seriously - what's up with Google Groups? Marco 2009/10/15 Avira a...@twitter.com Download Avira 2010 an key 2014 http://bit.ly/2dWFN5 http://bit.ly/2dWFN5 Download Avira 2010 an key 2014
[twitter-dev] Re: Download Avira 2010 an key 2014
ah - now I understand what you mean: set him as moderated in the members list. A bit funny to do that with the group owner... but yeah, maybe. 2009/10/15 Marco Kaiser kaiser.ma...@gmail.com sure, that removes them from the archive. but the messages are still sent out to the subscribers... Marco 2009/10/15 Abraham Williams 4bra...@gmail.com We are just going to have to moderate his messages like mine currently are. Abraham On Thu, Oct 15, 2009 at 06:17, Marco Kaiser kaiser.ma...@gmail.comwrote: uhm... should I ban @al3x now from the group?! seriously - what's up with Google Groups? Marco 2009/10/15 Avira a...@twitter.com Download Avira 2010 an key 2014 http://bit.ly/2dWFN5 http://bit.ly/2dWFN5 Download Avira 2010 an key 2014 -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | Intersect | http://intersect.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private.
[twitter-dev] Re: Updates to the retweet API payload
Well, you're not making use of JSON as JSON, and instead use brute-force methods to extract parts of it... I think it's a bit unfair to request that change to be made, as it would complicate things for everyone doing real JSON-to-OO mapping. Just my 2c. And no, retweet_status is perfectly valid - it's the property name in a status model, and it is assigned a status data model. Just a nested object. You don't have to name a member status just because it is a Status data type... Marco 2009/10/7 Zaudio si...@z-audio.co.uk Sure, I'll justify this mroe... One of our apps receives updates via the Streaming API and the various REST api methods (mentions, user timelines, friends/home timelines). We collect data as JSON as it's to date been faster and mor compact than alternatives... we can also then go on to use this directly client side in Jscript if we wish... We are caching all updates of interest in a db... thus parse them for the required data fields before storing them there. Currently the parser has to pull out the user node, and is then left with the root status node it is then simple to parse the separated nodes for all fields pertinant to the current operation. We make quick checks initially to determine the relevance of the message to the app's cached stream we want to check things like JUST created_at for the status (and not user) and then check the text property for certain markers. It is easy to find these efficiently in a JSON string without parsing the entire thing to objects as things stand... so we save a lot of server cpu cycles. It's fastest to this from the inner node outwards... this is where the 'wasted' cpu cycles are coming in here with the change for retweeted_status Status's of interest only have the further fields parsed that we want for out db copy... for example.. say you want to quickly check the id of the status to confirm if you have it in you db already or not... currently we just excluded the user node, and thent he id is in the remainder without conflict. Now add retweeted_status with it's user subnode To now get the id of the root status without parsing the entire string to objects... we pull it apart again from the inner node outwards... we now need to exclude the retweeted_status user subnode... this no longer has a unique start tag/definition... as there are TWO identical start tags in the string so we do a lot more work to ensure we get the retweeted_status and it's user node that we would if it had an alternative start tag. If it were instead retweeted_user, then we could extract that directly and easily, exclude it, then exclude the surrounding retweeted_status tag... and we've got the retweeted_status node separated... then we can procede as we do now with the rest... and if necessary use the retweeted_status as well. Hope that makes sense I agree that keeping it as user also makes good object sense... but then the retweeted_status is not 'status' anymore... and it is a status I'm suggesting soemthing similar for it's inner node.. Simon (Zaudio) On Oct 6, 12:01 pm, Marco Kaiser kaiser.ma...@gmail.com wrote: No, please don't change that to retweeted_user ... the data structure included as the retweeted status is a status, and that data structure has a user property. That's a very clear object model, and should map very well to JSON, as it's nested, not at the same level as the main user the retweet is received from. So by doing that change, you'd break the data model for a status, in that there are two version that need to be taken care of. Or can you explain in more depth why this would cause problems with reasonable JSON parsers that map strings to objects? 2009/10/6 Zaudio si...@z-audio.co.uk Another significant thought... could you 'please' consider changing the name of the user node INSIDE the retweeted_status node to say retweeted_user ? Thius will make JSON parsing way simpler... especially if the goal is to extract the retweeted_status when present; or do things like quickly find the date of the tweet... I alreayd have to contend with a created_at field in the user and status nodes... now that could double up... so owuld appreciate an easier to find retweeted user node for JSON parsability Thanks Simon (Zaudio) On Oct 4, 8:16 am, John Kalucki jkalu...@gmail.com wrote: Retweetis an invasive feature with many deep dependency paths. Firm dates would be useful, but they aren't possible in this particular situation. This makes planning for downstream folks difficult. I'd be ready for the slight possibility of low-volume retweets mid-to- late week, with a high chance the following week, and perhaps a near- unity chance of low-volume retweets the week after that. So, for critical code, any time now. As for full-roll-out, that would be even more of a guessing game. -John
[twitter-dev] Re: Updates to the retweet API payload
No, please don't change that to retweeted_user ... the data structure included as the retweeted status is a status, and that data structure has a user property. That's a very clear object model, and should map very well to JSON, as it's nested, not at the same level as the main user the retweet is received from. So by doing that change, you'd break the data model for a status, in that there are two version that need to be taken care of. Or can you explain in more depth why this would cause problems with reasonable JSON parsers that map strings to objects? 2009/10/6 Zaudio si...@z-audio.co.uk Another significant thought... could you 'please' consider changing the name of the user node INSIDE the retweeted_status node to say retweeted_user ? Thius will make JSON parsing way simpler... especially if the goal is to extract the retweeted_status when present; or do things like quickly find the date of the tweet... I alreayd have to contend with a created_at field in the user and status nodes... now that could double up... so owuld appreciate an easier to find retweeted user node for JSON parsability Thanks Simon (Zaudio) On Oct 4, 8:16 am, John Kalucki jkalu...@gmail.com wrote: Retweetis an invasive feature with many deep dependency paths. Firm dates would be useful, but they aren't possible in this particular situation. This makes planning for downstream folks difficult. I'd be ready for the slight possibility of low-volume retweets mid-to- late week, with a high chance the following week, and perhaps a near- unity chance of low-volume retweets the week after that. So, for critical code, any time now. As for full-roll-out, that would be even more of a guessing game. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Oct 4, 6:43 am, Zaudio si...@z-audio.co.uk wrote: Hey John, Thanks for that... can you put an earliest date on 'very soon' please - just so I know how long we've got? Thanks Simon (Zaudio) On Oct 3, 8:15 pm, John Kalucki jkalu...@gmail.com wrote: There are plans to filter retweets from various resource, see the documentation. However, it would be most prudent to assume that retweets will eventually show up everywhere, and handle them appropriately, or at least tolerate them wherever they are found. They should start appearing in low volumes in all /1/statuses/* resources on the Streaming API very soon. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Oct 3, 10:33 am, Zaudio si...@z-audio.co.uk wrote: This sounds a lot more sensible... Importantly, where can we expect this newpayloadto be returned... any of the following methods as well? REST API statuses/mentions statuses/user Streaming API/Shadow I need to know in advance of such an addition to any of these, as otherwise the parser on one of our apps gets broken until it's recoded to handle theretweetpayload... or is the ONLY was to get these vie theretweetmethods and the new home_timeline ? If so, what about apps that mainly make use of the Streaming API for tweets? Thanks Simon (Zaudio)- Hide quoted text - - Show quoted text -
[twitter-dev] Re: U.S.Senator Orrin Hatch's Request To Follow Me!
http://help.twitter.com is your friend 2009/10/6 Taz redskin76...@gmail.com I click on the friend request link from my e-mail to go into twitter and accept it and it says no follow request at this time and I have not accepted or denied the senator's follow request.What do I do to accept it?
[twitter-dev] Re: Updates to the retweet API payload
Hi, first of all, let me say that I think this change to the relation between the retweet and the retweeted status makes much sense - it feels much more natural to see it as user A retweets user B instead of user B retweeted by user A, especially if you don't follow B. A couple of questions inline below: 2009/10/1 Marcel Molina mar...@twitter.com After experimenting with this approach we've decided that it's a better bet to craft a payload that will degrade far more gracefully. So we've redesigned the retweet payload. Rather than having the original tweet as the top level status with embedded details about who retweeted it, the retweet is the top level object and within it we include the original tweet and its author. In your original design, the retweeted message was about to appear in a user's stream, by the original author. I understand that one of the main objectives of this change was to avoid the confusion of people appearing in home timelines that users aren't following. Does that also mean that you'll now show the retweet as sent by the retweeter, not the original poster, and give credit to the original poster in the meta information for a tweet on your web interface? (kind of the opposite of what the first version did) You'll have full access to the entire retweeted status and user as well as the original tweet and its user. So you don't have to make any additional API calls and should have everything you need to display a retweet distinctively with attribute to both the original author and the retweeter. Are you considering a retweet as a single entity, or as part of a number of retweets of the original message? In other words, is the an by 5 others (if multiple people retweeted a message) still something you want to show somehow? If more than one of my friends retweets a message, should this be displayed as multiple messages now, coming from different people, or are you still collapsing retweets? (the latter doesn't make much sense anymore IMO, as with the inverted relation, the retweet is now coming from the retweeter, not the original poster anymore) In other words, these retweeted statuses look a whole lot like regular statuses. This new design was our instinct to begin with and we probably should have gone with it. We think it's better and hope you do too. All the same documented resources will exist. Only the payloads change. The /statuses/retweets/id.format endpoint returned a list of retweet_details before - as I understand it, this data structure no longer exists. What will it return instead? The following timeline should contain examples of the updated retweet payload. You can use this to test consuming retweets. curl http://twitter.com/statuses/user_timeline/testiverse.xml curl http://twitter.com/statuses/user_timeline/testiverse.json In the event that new tweets go into the above timeline that push the retweets out, you can access a few directly at the following urls: curl http://twitter.com/statuses/show/4452134416.xml curl http://twitter.com/statuses/show/4452466408.xml curl http://twitter.com/statuses/show/4349744308.xml The above payloads don't contain a retweet_count element yet and they probably will. Other than that we don't suspect any more major changes as we approach a full public launch. As always, though, we're open and solicitous of everyone's feedback. If there is no retweet_count, how can apps know if they need to display something like and by 5 others? How can they know if it is worth requesting a list of retweets (doesn't make sense if there is just one retweet, as it would waste an API request)? Or (see question above) is showing the list of retweets considered a deprecated feature? Thanks. And finally: when will the retweet API be available for beta testers again? Thanks, Marco -- Marcel Molina Twitter Platform Team http://twitter.com/noradio
[twitter-dev] Re: Draft: Twitter Rules for API Use
2009/9/11 Dean Collins d...@cognation.net 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. have you considered that there might not be a fixed number, but a pattern of requests that they are looking for? have you considered that revealing this pattern (or even the number, if that's what it is) cannot be in Twitter's interest to fight spammers, as they could make very good use of that information and adjust their bots accordingly? some rules just cannot be made public, for very good reasons. yes, that's annoying - but to be blunt, if you're app is getting caught by those rulse, it's likely that Twitter does consider what your are doing as being spam. And I am not saying that it is (I don't even know what you do), it's just a logical consequence: rules to prevent spam - app caught by rules - app is considered doing spam 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 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
dude (to take your word), I was replying to your give us an exact number comment, not to whatever happened to one of your twitter accounts. That might be something completely unrelated, and as I know nothing about that, I don't dare to even comment about that. all I'm saying is that 1) an exact number might not exist, and 2) they have good reason not to reveal the exact trigger for an account suspension. Name any other service that gives you all the details. Oh, and by the way, have fun on Facebook, this is from their TOS: If you violate the letter or spirit of this Statement, or otherwise create possible legal exposure for us, we can stop providing all or part of Facebook to you. pretty general, too, isn't it? Marco 2009/9/11 Dean Collins d...@cognation.net -- *From:* twitter-development-talk@googlegroups.com [mailto: twitter-development-t...@googlegroups.com] *On Behalf Of *Marco Kaiser *Sent:* Friday, September 11, 2009 10:43 AM *To:* twitter-development-talk@googlegroups.com *Subject:* [twitter-dev] Re: Draft: Twitter Rules for API Use 2009/9/11 Dean Collins d...@cognation.net 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. have you considered that there might not be a fixed number, but a pattern of requests that they are looking for? have you considered that revealing this pattern (or even the number, if that's what it is) cannot be in Twitter's interest to fight spammers, as they could make very good use of that information and adjust their bots accordingly? some rules just cannot be made public, for very good reasons. yes, that's annoying - but to be blunt, if you're app is getting caught by those rulse, it's likely that Twitter does consider what your are doing as being spam. And I am not saying that it is (I don't even know what you do), it's just a logical consequence: rules to prevent spam - app caught by rules - app is considered doing spam We’re happy to play by the rules, just spell out what those rules clearly are. Regards, Dean Collins Dude all I did yesterday was startup my @LiveNFLchat account for the first game of the season which hadn’t really been used since last season. Basically fired up TwitterKarma to delete accounts not following me from last seasons posts and then started following people chatting about the Titans V’s Steelers season opener game last night. I didn’t send a single direct message and apart from two posts about the volume of twittersphere nfl traffic and that was it. Hardly spamming. Basically I’m fairly sure my account was singled out because of my on going legal issues with a totally separate and unrelated project. The two projects are totally unrelated but I get the feeling if I fire up and use any of my 22 twitter accounts they are all going to be closed down 1 by 1. Like is said, speel out the rules and people will use them – oitherwise I’m just as happy to move my apps off twitter and move to facebook or some other platform. Twitter is where it is BECAUSE of third party application developers not in spite of it. Ben’s comments are spot on how are you supposed to invest your time and energy when you can be shut down for not following ‘unspecified rules’. Regards, Dean Collins Live Chat Concepts Inc d...@livechatconcepts.com d...@livechatconcepts.com+1-212-203-4357 New York +61-2-9016-5642 (Sydney in-dial). +44-20-3129-6001 (London in-dial).
[twitter-dev] Search API sometimes returning random tweets mixed in?
Hi, we are receiving an increasing number of reports from users about search results containing tweets that don't match the search query. It doesn't seem to be reproducable, i.e. a later request for the same query does not contain the false results. We've also seen from user reports on twitter that other clients seem to be affected. Anyone got an idea what's going on? Or can someone confirm that he's also running into that issue? Thanks, Marco
[twitter-dev] Re: Search API Results Mismatches
Hi Chad, we are getting reports from the users of our desktop clients, so the user agent will either contain twhirl or Seesmic Desktop. We'll try to get the queries used from our users, but unfortunately, we'll not be able to provide any of the other information, as it all happens on users' computers, and we can't log all that data for every request. Anyway, thanks for looking into it. The last report we got was for the search query #openpractice - I can send you a screen shots of the results as displayed in the client if you want. Thanks, Marco 2009/8/20 Chad Etzel jazzyc...@gmail.com Hi all, If you are experiencing search results that don't match your query, if you can please log the following information and send it to a...@twitter.com, it will help our Search team debug this problem. -Your external IP -Your user-agent -Your search query -The timestamp -The results -The search server that served the results (will be in HTTP headers) Thanks, -Chad
[twitter-dev] Re: Twitter Update, 8/9 noon PST
most likely because you subscribed to the group
you can go to http://groups.google.com/group/twitter-development-talk/ to
manage your subscription status
Marco
2009/8/10 timothy willan timothywil...@gmail.com
Hello Ryan I'm timothy not surwe why I'm receiving all twitter Development
emails, let me know Thanks
On Sun, Aug 9, 2009 at 3:13 PM, Ryan Sarver rsar...@twitter.com wrote:
*Finally* have what we hope is good news for everyone. As of about 10
minutes ago we have been able to restore critical parts of API operation
that should have great affect on your apps. As such, most of your apps
should begin to function normally again. I have tested a few OAuth apps and
they seem to be working as expected.
Please test your apps from their standard configs to see what results you
get and let us know. I am primarily interested in unexpected throttling and
issues with OAuth.
I look forward to hearing the results and thanks again for your
assistance.
Best, Ryan
--
The solution to building a strong country is to make its citizens
strong...To make U.S. citizens strong you need to make them their own
boss... in control of their own destiny... happy about life and the
direction that life is taking them... that is what will make the U.S.
citizens strong again. THAT is what built this country into the FREE nation
that it is today{.Winning means being unafraid to lose.
timothywil...@gmail.com
Timothy Willan
2214 Ardenwood dr.
Spring Hill Fl. 346109
352-585-1264
[twitter-dev] Re: DDoS Status Update
I'm sure they would let you know first... Get real. Sent from my iPhone On 07.08.2009, at 21:02, Jesse Stay jesses...@gmail.com wrote: Thanks for the communication - this is good. Just curious - with entire businesses being put out of place, and rumors that the Russian Gov't may be behind such attacks, is Twitter communicating with Homeland Security about this? To me this seems like a matter of national security even more than it is a Twitter issue. The US economy is being attacked because of this. Not to sound too radical - I'm just genuinely curious when the Government is going to get involved. (and thank you for doing what you can - I'm sure I speak for all when I say we feel your pain) Jesse On Fri, Aug 7, 2009 at 2:05 PM, Ryan Sarver rsar...@twitter.com wrote: I wanted to send everyone an update to let you know what has been happening, the known issues, some suggestions on how to resolve them and some idea of how to move forward. Whats been happening As you know all too well Twitter, among other services, has been getting hit pretty hard with a DDoS attack over the past 24+ hours. Yesterday we saw the attack come in a number of waves and from a number of different vectors increasing in intensity along the way. We were able to stabilize our own service for a bit, hence Biz's post saying all was well, but that didn't mean the attacks had ceased. In fact, at around 3am PST today the attacks intensified to almost 10x of what it was yesterday. In order for us to defend from the attack we have had to put a number of services in place and we know that some of you have gotten caught in the crossfire. Please know we are as frustrated as you are and wish there was more we could have communicated along the way. Known Issues - HTTP 300 response codes - One of the measures in thwarting the onslaught requires that all traffic respect HTTP 30x response codes. This will help us identify the good traffic from the bad. - General throttling - Try to throttle your services back as much as possible for you to continue operating. We are working on our end to better understand the logic used in throttling traffic on the edge of the network and will communicate what we can, but the best idea is to just throttle back as much as you can in the mean time. - Streaming API - as part of the edge throttling we know requests to the Streaming API with lists of keywords or uses are getting dropped because the request is too large. We are working to get this filter removed and will update the list when we know more. - Unexpected HTTP response codes - we know people are seeing a lot of other weirdness and we aren't exactly sure what to attribute the various issues to, but know that you aren't alone. As the attacks change our tactics for defense will likely need to change as well, so stay active on the list and let us know what problems you are seeing and we will do our best to help guide you along. Moving forward We will try to communicate as much as we can so you guys are up to speed as things change and progress. I personally apologize for not communicating more in the mean time but there hasn't been much guidance we have been able to give other than hold tight with us. We fully appreciate all the long hours you are putting in to keep your apps running and supporting your users and know we are frustrated with you. Continue to watch this list, status.twitter.com and @twitterapi for updates Thanks for your patience, Ryan PM, Platform Team @rsarver
[twitter-dev] Re: Updating the APIs authentication limiting policy
I think Dewald's concern is very valid - and even though OAuth might solve it, the reality is that most (if not all) desktop and mobile apps are using Basic Auth today for various reasons, so if you implement this policy as described, there's a pretty high risk that many users can be locked out of twitter from their usual ways to access it. Also, again a reminder that AFAIK the last official status re: OAuth from Twitter was that it is still in beta, and therefore not recommended for production use - or has there been another announcement that I missed? Marco 2009/7/24 Doug Williams d...@twitter.com Well said Joshua. Dewald, you have identified the risk of using basic authentication. If your users being locked out due to malicious behavior, you should either implement further user-level rate limiting on your side or adopt OAuth. Are there any other glaring omissions in our thinking or should we proceed with this as our solution? Thanks, Doug On Fri, Jul 24, 2009 at 11:08 AM, Joshua Perryj...@6bit.com wrote: Jim's concern is valid, fortunately OAuth is immune to brute-force attacks once the access key has been issued to an application. For this reason alone I would urge people to switch to OAuth if at all possible. I would hope (and assume) that if login attempts for an account are locked out that a user would still be able to successfully use an already authorized OAuth driven application. Unfortunately allowing a successful un/pw login while an account is locked out even when the correct password is presented effectively bypasses the whole reason for a lockout in the first place, preventing brute-force password attempts. If an attacker used a dictionary or brute-force attack and the account was locked out after 15 attempts, then they could continue trying even though the system replied locked out; if they eventually sent the correct password it would just bypass the lockout and they would then know the correct password. Perhaps Twitter could implement a selective captcha, I know they are annoying but if executed properly it could be effective protection against brute-force and dictionary attacks. Say after 3 or 4 failed attempts without a captch the API would then include a captcha image URL in it's response that the application would then need to show to the person and include the user's response with the next authentication attempt as a header or POST variable. The site stackoverflow.com does this to great effect, if you create posts quicker than a certain threshold which a person would not exceed then they pop a captcha up, in the normal use of the site you will never see one; I've only hit two captchas in the last in the last 8 months using the site. Josh Dewald Pretorius wrote: Jim raised a huge weakness with the authentication rate limiting that could essentially break third-party apps. Anybody can try to add anybody else's Twitter account to a third-party app using an invalid password. If they do that 15 times with a Twitter account, the real owner of that Twitter account, who may have added his account a long time ago with the correct password, is locked out from using that app for an hour. I believe you will absolutely have to reset / remove the lock as soon as the Twitter account uses the correct password. On Jul 22, 4:58 pm, jim.renkel james.ren...@gmail.com wrote: My concern with this proposal is that it opens up denials of service, not to twitter.com, but to associated sites such as twitpic, or my site twxlate, among others For example, Lance Armstrong is a heavy user of twitpic. It is very easy for anyone to find Lance's twitter ID (@lancearmstrong), view his status updates, and see that he is a frequent user of twitpic. Now, someone that is unhappy with Lance, say one of George Hincapie's ardent fans that really believes that Lance was a significant contributor to George not winning the maillot jeune last Sunday, could go to twitpic, fail to login as Lance the requisite number of times, and deny Lance access to twitpic. Not only celebrities would or could be subject to such denials of service. I notice that @dougw occasionally uses twitpic! :-) One solution to this problem is to add to each twitter account another private ID. By default this private ID would be equal to the existing (public) ID (If not equal to the account's public ID, it would have to be unique among all twitter IDs, both public and private.). The public ID would be used just as the existing twitter ID is now: others would use it to follow, mention, DM, etc., the user. But the user MUST use their private ID for authenticated requests through the API, and CAN also use it for non-authenticated requests. In either case, twitter would treat a request from a private ID as if it came from the corresponding public ID. Blocking the
[twitter-dev] Re: last inserted ID
Not sure if I miss your question, but the response body for a successful status update returns a full status object, including the new ID. Hope this helps, Marco 2009/6/23 Peter Denton petermden...@gmail.com Hello, Is there any chance in the future a http 200 response from a status update could return the newly created twitter ID. Meaning, dup the effect of mysql_insert_id()?
[twitter-dev] Re: Search API to require HTTP Referrer and/or User Agent
Doug, citing from your original mail: Any request not including this information will be returned a 403 Forbidden response code by our web server. How does it map to what you say now, that a best effort is sufficient, if you reject any request without those header(s) with a 403 response? Again, I am not fearing an IP or User-Agent ban because of not-sent header data; what I fear is a rejection of search requests when the header data is removed by network gear. At least that's how I read your announcement for this change - or am I wrong? Will you only reject requests for certain IPs that have high volume based on the Referrer/User-Agent requirement, but in general the Search API doesn't require it to be present? Marco 2009/6/17 Doug Williams d...@twitter.com For most applications, enforcement of this requirement will be subject to manual review. We want a marker (Referrer and/or User Agent) to help understand who top searchers are when problems arise and if we can determine a better data access plan for their needs. End-users and clients never hit our trip-wires as they are not individually querying the API with enough frequently warrant a manual review. For your needs, Marco, a best effort to include a the requested data is sufficient on our end and will not cause any problems if the data is removed by network gear. Services that are in cloud-based hosts, such as EC2 and AppEngine will however be subject to programmatic enforcement of this policy. Additionally, we reserve the right to add hosts to this if we find that a host is being used to exploit our service. This is to protect the service against abuse which often comes from shared hosts such as these. Thanks, Doug On Tue, Jun 16, 2009 at 3:19 PM, Marco Kaiser kaiser.ma...@gmail.comwrote: You are still missing my point - desktop clients may not be able to send a User Agent or Referrer, based on the network infrastructure the use is locked into. Nothing in your repsonse addressed this issue. I am fully willing to send the requested data in the clients (and I already do), but I have no means to make sure they reach you. So if they don't, even though I am doing all you ask me to do, you'll still lock out the user from search in his client. I am not worried to be blocked or whatever, it's merely that the requirement to provide one of the two HTTP headers may not be possible for client apps. So low volume clients (in terms of client-per-IP numbers, not overall) clearly WILL be affected. Marco 2009/6/17 Doug Williams d...@twitter.com As you have determined, we just a better way to track who is making requests and at what volume. If you are doing janky things and we don't know who you are (no referrer or user agent) then we have no contact for your application. We will block the IP address and move on. However if you would like to give us a chance to work with you before terminating your access unexpectedly, please provide us with enough of a hint (through a HTTP Referrer and/or User Agent) to determine who you are so we can have any necessary conversations. We do not feel that this is not an unreasonable request. Low volume clients will not be affected. Anyone doing anything that bubbles to the top of logs however may be subject to scrutiny. Thanks, Doug -- Do you follow me? http://twitter.com/dougw On Tue, Jun 16, 2009 at 2:47 PM, Chad Etzel jazzyc...@gmail.com wrote: Perhaps some sort of signature/app value in the URL request query string? That will make it through proxies and firewalls, and is just as easily spoofed as HTTP-Referrer and User-Agents... -Chad On Tue, Jun 16, 2009 at 5:36 PM, Marco Kaiserkaiser.ma...@gmail.com wrote: Matt, far from getting into RFC debates, but really concerned for the non-server apps out there, which may not have full control over the network infrastructure they run on. If I set up my own server(s) at a data center, I sure can take care of sending you the right referrer and user-agent, but unfortunately that's not the case in many environments behind firewalls and / or proxies. What's your point on that? I fully understand your intention and the need for getting some identification - so happy to discuss anything that'll also work through restricted network access. Thanks, Marco 2009/6/16 Matt Sanford m...@twitter.com Hi there, While all of this flame is keeping my feet warm it's not really productive. This isn't Slashdot comments, let's try and remain on topic rather the getting into RFC debates. To be even more explicit than my previous email: Use the user-agent. Referrer will be taken care of by browsers and I see as a fallback for client-side JSON users rather than a replacement for a user-agent. The subsequent reply from Michael Ivey about how this helps is dead on. With no context at all I'm forced to block all of ECS/AppEngine/Yahoo Pipes is one person misbehaves
[twitter-dev] Re: Search API to require HTTP Referrer and/or User Agent
I agree with Stuart, this might be tricky for client applications that are running behind firewalls / proxies that might remove both header fields, and neither the app author nor the user might have any control over this. Finally, that means you'll lock out those people from using search in their preferred twitter apps. Marco 2009/6/16 Stuart stut...@gmail.com 2009/6/16 Naveen Kohli naveenko...@gmail.com Redefining HTTP spec, eh :-) Whatever makes twitter boat float. Lets hope for the best. Just concerned that some firewalls or proxies tend to remove referrer. What a completely ridiculous thing to say. It's not redefining anything. If Twitter want to require something in order to access their service they absolutely have that right. It's not like they're saying every HTTP server should start requiring these headers. It's true that some firewalls and proxies remove the referrer header, and some also remove the user agent header. I'm somewhat unclear on exactly how this stuff is supposed to help. If an application sets out to abuse the system they'll simply set the headers so they look like a normal browser. I don't see what purpose requiring these headers to be something useful will actually serve. IMHO you might as well require the source parameter for all API requests that use basic auth which is simple for all apps to implement; OAuth clearly carries identification with it already. -Stuart -- http://stut.net/projects/twitter On Tue, Jun 16, 2009 at 1:05 PM, Stuart stut...@gmail.com wrote: It's optional in the HTTP spec, but mandatory for the Twitter Search API. I don't see a problem with that. Doug: Presumably the body of the 403 response will contain a suitable descriptive error message in the usual format? -Stuart -- http://stut.net/projects/twitter 2009/6/16 Naveen Kohli naveenko...@gmail.com: Why would you make decision based on Referrer which is an OPTIONAL header field in HTTP protocol? Making decision based on something that is REQUIRED may be more appropriate. On Tue, Jun 16, 2009 at 12:33 PM, Doug Williams d...@twitter.com wrote: Hi all, The Search API will begin to require a valid HTTP Referrer, or at the very least, a meaningful and unique user agent with each request. Any request not including this information will be returned a 403 Forbidden response code by our web server. This change will be effective within the next few days, so please check your applications using the Search API and make any necessary code changes. Thanks, Doug -- Naveen K Kohli http://www.netomatix.com -- Naveen K Kohli http://www.netomatix.com
[twitter-dev] Re: Search API to require HTTP Referrer and/or User Agent
Matt, far from getting into RFC debates, but really concerned for the non-server apps out there, which may not have full control over the network infrastructure they run on. If I set up my own server(s) at a data center, I sure can take care of sending you the right referrer and user-agent, but unfortunately that's not the case in many environments behind firewalls and / or proxies. What's your point on that? I fully understand your intention and the need for getting some identification - so happy to discuss anything that'll also work through restricted network access. Thanks, Marco 2009/6/16 Matt Sanford m...@twitter.com Hi there, While all of this flame is keeping my feet warm it's not really productive. This isn't Slashdot comments, let's try and remain on topic rather the getting into RFC debates. To be even more explicit than my previous email: Use the user-agent. Referrer will be taken care of by browsers and I see as a fallback for client-side JSON users rather than a replacement for a user-agent. The subsequent reply from Michael Ivey about how this helps is dead on. With no context at all I'm forced to block all of ECS/AppEngine/Yahoo Pipes is one person misbehaves. Nobody likes that. Since search is not authenticated OAuth does not really help here. We may be forced to make search authenticated if we can't find a reasonable way to sort the good from the bad. This is a first attempt at helping us cut out poorly build spam scripts and shorten the time I spend researching each abuser. It saves time and lets me fix more bugs, assuming I don't spend the newly saved time in RFC debates, that is :) Thanks; – Matt Sanford / @mzsanford Twitter Dev On Jun 16, 2009, at 12:39 PM, Stuart wrote: 2009/6/16 Naveen Kohli naveenko...@gmail.com Redefining HTTP spec, eh :-) Whatever makes twitter boat float. Lets hope for the best. Just concerned that some firewalls or proxies tend to remove referrer. What a completely ridiculous thing to say. It's not redefining anything. If Twitter want to require something in order to access their service they absolutely have that right. It's not like they're saying every HTTP server should start requiring these headers. It's true that some firewalls and proxies remove the referrer header, and some also remove the user agent header. I'm somewhat unclear on exactly how this stuff is supposed to help. If an application sets out to abuse the system they'll simply set the headers so they look like a normal browser. I don't see what purpose requiring these headers to be something useful will actually serve. IMHO you might as well require the source parameter for all API requests that use basic auth which is simple for all apps to implement; OAuth clearly carries identification with it already. -Stuart -- http://stut.net/projects/twitter On Tue, Jun 16, 2009 at 1:05 PM, Stuart stut...@gmail.com wrote: It's optional in the HTTP spec, but mandatory for the Twitter Search API. I don't see a problem with that. Doug: Presumably the body of the 403 response will contain a suitable descriptive error message in the usual format? -Stuart -- http://stut.net/projects/twitter 2009/6/16 Naveen Kohli naveenko...@gmail.com: Why would you make decision based on Referrer which is an OPTIONAL header field in HTTP protocol? Making decision based on something that is REQUIRED may be more appropriate. On Tue, Jun 16, 2009 at 12:33 PM, Doug Williams d...@twitter.com wrote: Hi all, The Search API will begin to require a valid HTTP Referrer, or at the very least, a meaningful and unique user agent with each request. Any request not including this information will be returned a 403 Forbidden response code by our web server. This change will be effective within the next few days, so please check your applications using the Search API and make any necessary code changes. Thanks, Doug -- Naveen K Kohli http://www.netomatix.com -- Naveen K Kohli http://www.netomatix.com
[twitter-dev] Re: Search API to require HTTP Referrer and/or User Agent
You are still missing my point - desktop clients may not be able to send a User Agent or Referrer, based on the network infrastructure the use is locked into. Nothing in your repsonse addressed this issue. I am fully willing to send the requested data in the clients (and I already do), but I have no means to make sure they reach you. So if they don't, even though I am doing all you ask me to do, you'll still lock out the user from search in his client. I am not worried to be blocked or whatever, it's merely that the requirement to provide one of the two HTTP headers may not be possible for client apps. So low volume clients (in terms of client-per-IP numbers, not overall) clearly WILL be affected. Marco 2009/6/17 Doug Williams d...@twitter.com As you have determined, we just a better way to track who is making requests and at what volume. If you are doing janky things and we don't know who you are (no referrer or user agent) then we have no contact for your application. We will block the IP address and move on. However if you would like to give us a chance to work with you before terminating your access unexpectedly, please provide us with enough of a hint (through a HTTP Referrer and/or User Agent) to determine who you are so we can have any necessary conversations. We do not feel that this is not an unreasonable request. Low volume clients will not be affected. Anyone doing anything that bubbles to the top of logs however may be subject to scrutiny. Thanks, Doug -- Do you follow me? http://twitter.com/dougw On Tue, Jun 16, 2009 at 2:47 PM, Chad Etzel jazzyc...@gmail.com wrote: Perhaps some sort of signature/app value in the URL request query string? That will make it through proxies and firewalls, and is just as easily spoofed as HTTP-Referrer and User-Agents... -Chad On Tue, Jun 16, 2009 at 5:36 PM, Marco Kaiserkaiser.ma...@gmail.com wrote: Matt, far from getting into RFC debates, but really concerned for the non-server apps out there, which may not have full control over the network infrastructure they run on. If I set up my own server(s) at a data center, I sure can take care of sending you the right referrer and user-agent, but unfortunately that's not the case in many environments behind firewalls and / or proxies. What's your point on that? I fully understand your intention and the need for getting some identification - so happy to discuss anything that'll also work through restricted network access. Thanks, Marco 2009/6/16 Matt Sanford m...@twitter.com Hi there, While all of this flame is keeping my feet warm it's not really productive. This isn't Slashdot comments, let's try and remain on topic rather the getting into RFC debates. To be even more explicit than my previous email: Use the user-agent. Referrer will be taken care of by browsers and I see as a fallback for client-side JSON users rather than a replacement for a user-agent. The subsequent reply from Michael Ivey about how this helps is dead on. With no context at all I'm forced to block all of ECS/AppEngine/Yahoo Pipes is one person misbehaves. Nobody likes that. Since search is not authenticated OAuth does not really help here. We may be forced to make search authenticated if we can't find a reasonable way to sort the good from the bad. This is a first attempt at helping us cut out poorly build spam scripts and shorten the time I spend researching each abuser. It saves time and lets me fix more bugs, assuming I don't spend the newly saved time in RFC debates, that is :) Thanks; – Matt Sanford / @mzsanford Twitter Dev On Jun 16, 2009, at 12:39 PM, Stuart wrote: 2009/6/16 Naveen Kohli naveenko...@gmail.com Redefining HTTP spec, eh :-) Whatever makes twitter boat float. Lets hope for the best. Just concerned that some firewalls or proxies tend to remove referrer. What a completely ridiculous thing to say. It's not redefining anything. If Twitter want to require something in order to access their service they absolutely have that right. It's not like they're saying every HTTP server should start requiring these headers. It's true that some firewalls and proxies remove the referrer header, and some also remove the user agent header. I'm somewhat unclear on exactly how this stuff is supposed to help. If an application sets out to abuse the system they'll simply set the headers so they look like a normal browser. I don't see what purpose requiring these headers to be something useful will actually serve. IMHO you might as well require the source parameter for all API requests that use basic auth which is simple for all apps to implement; OAuth clearly carries identification with it already. -Stuart -- http://stut.net/projects/twitter On Tue, Jun 16, 2009 at 1:05 PM, Stuart stut...@gmail.com wrote: It's optional in the HTTP spec, but
[twitter-dev] Re: New Public Streaming API Resource - Follow
2009/5/13 John Kalucki jkalu...@gmail.com I'll attempt to answer these questions, but I can only do so with some speculation and humble ignorance. 1) OAuth allows clients to authenticate with the Twitter REST API via third-party services. These services should not also need to interact with the Streaming API on a per client basis. Instead, the service should establish a single query that satisfies all clients' needs. This may not be practical in all cases, but I suspect we can approximate the desired behavior with the current set of primitives. John, in your original mail on this thread you wrote: For example, a desktop client could simulate a user's /home timeline, minus private updates and mentions, via the /follow resource. Continuous polling would no longer be necessary or desired. This doesn't match the scenario from above, where you refer to using the streaming endpoints from a single query per service. So still the question how a desktop client that is trying to do OAuth and not ask users for their passwords can use the streaming API is open - or are you saying that those clients just cannot use it? I think this would discourage many desktop developers from even looking into integrating OAuth for their clients, which as I assume can't be in twitter's interest. 2) There are no immediate plans to support HTTPS, mainly because we're not really trying to keep the data private. Also, and I am probably totally wrong here, I don't think we use HTTPS on the main WWW site or on the REST API, so this doesn't make things much worse than they already are. A possible workaround would be for sensitive service to create an account just for streaming. Should the password be compromised, there's only a denial of service risk and no further risk. Again, this doesn't help much in the context of desktop app use, as it would have to use it's authenticated user's credentials. Clients just shouldn't send a cleartext password over an unecrypted connection IMO. Marco On May 13, 11:18 am, Marco Kaiser kaiser.ma...@gmail.com wrote: John, this looks pretty interesting! Two questions: 1) you are requiring to send a username and password for Basic Auth - how does that map to apps / services using OAuth, as they won't have access to a user's passwords? (and related, how does this fit into your general roadmap to move everything to OAuth?) 2) the docs only mention http as a protocol, not https. In combination with requiring passwords, only making http available seems quite unsecure. Any plans to also support https soon (or any other mechanism which gives better security?) Thanks, Marco 2009/5/13 John Kalucki jkalu...@gmail.com Chad, Yes, I think this is called POSTDATA in browsers. I don't recall what the actual name of this part of the HTTP protocol is, but it's the body section after the headers. I corrected the file name error. Thanks. -John On May 12, 8:49 pm, Chad Etzel jazzyc...@gmail.com wrote: Hi John, /follow looks very interesting. Since you're asking for feedback I'm copying the follow parameter example documentation: Example: Create a file called 'follow' that contains, exactly and excluding the quotation marks: follow=12 13 15 16 20 87. Execute: curl -d @followinghttp://stream.twitter.com/follow.json -uAnyTwitterUser:Password.You will receive JSON updates from Jack Biz, Crystal, Ev, Krissy, but not from Jeremy, as he's a private user. I'm assuming that follow is just a POSTDATA variable in the normal case (you're just using curl's file posting ability in the example)? In the example, should the file be called following instead of follow (since you are using -d @following in the curl line)? Thanks, -Chad On Tue, May 12, 2009 at 11:24 PM, John Kalucki jkalu...@gmail.com wrote: Note: The Streaming API is currently under a limited alpha test, details below. The /follow Streaming API resource is now publicly available. This resource streams near-real-time public updates posted by an arbitrary set of users. Streaming by user_id may be interesting to a variety of developers who wish to provide a nearly instantaneous experience without the drawbacks of continuous polling, polling rate limits, auto- following and follow limits. For example, a desktop client could simulate a user's /home timeline, minus private updates and mentions, via the /follow resource. Continuous polling would no longer be necessary or desired. Upon receipt of a new streamed message, the REST API may be periodically polled to back-fill mentions, private statuses and other updates not available via the Streaming API. This stream may also be interesting to service developers that follow their subscribers solely to receive their replies or for data mining purposes
[twitter-dev] Re: New Public Streaming API Resource - Follow
John, I have all the patience you need ;-) 2009/5/14 John Kalucki jkalu...@gmail.com Marco, Once again, I beg patience with my ignorance of Twitter's larger authentication plans. For the time being, the primary use for Hosebird is delivering streams to partners, data analyzers, and other developers looking to experiment with statuses in a way that the purpose-built REST API might not allow. For this case, basic auth is probably acceptable, barely, as it is typically server to server. Desktop clients have much greater exposure to man-in-the-middle snooping, so I fully appreciate the concern about passwords. Yes - and I agree with you that all the restricted Hosebird streams are really targeting the server-side market. I was just following your thought of making use of the public (lowest-tier) streams, and especially the follow stream, in a desktop client. That's where my concerns come from. It never occurred to me that OAuth might be a thing for the desktop. In my experience, clients are mostly using basic auth, but it certainly would be nice if that evolved. I think all I can say at this point is, if streaming to the desktop becomes a Big Thing, we'll look into adding a better authentication mechanism to the Streaming API. I'd love to share yoour opinion - I don't think OAuth is a model that works well for any desktop application, and that storing a user's password on his own computer isn't a big deal (we do this everyday with cached passwords in browsers, mail clients, IM apps etc). But Twitter is clearly driving the whole dev community towards OAuth (just look at the deprecation of new source parameters and your encouragement to use OAuth instead), so I was wondering how this new API fits into that. Anyway, thanks for your answers, and I am well aware that this is an alpha test and subject to change anyway. Marco -John On May 14, 2:56 am, Marco Kaiser kaiser.ma...@gmail.com wrote: 2009/5/13 John Kalucki jkalu...@gmail.com I'll attempt to answer these questions, but I can only do so with some speculation and humble ignorance. 1) OAuth allows clients to authenticate with the Twitter REST API via third-party services. These services should not also need to interact with the Streaming API on a per client basis. Instead, the service should establish a single query that satisfies all clients' needs. This may not be practical in all cases, but I suspect we can approximate the desired behavior with the current set of primitives. John, in your original mail on this thread you wrote: For example, a desktop client could simulate a user's /home timeline, minus private updates and mentions, via the /follow resource. Continuous polling would no longer be necessary or desired. This doesn't match the scenario from above, where you refer to using the streaming endpoints from a single query per service. So still the question how a desktop client that is trying to do OAuth and not ask users for their passwords can use the streaming API is open - or are you saying that those clients just cannot use it? I think this would discourage many desktop developers from even looking into integrating OAuth for their clients, which as I assume can't be in twitter's interest. 2) There are no immediate plans to support HTTPS, mainly because we're not really trying to keep the data private. Also, and I am probably totally wrong here, I don't think we use HTTPS on the main WWW site or on the REST API, so this doesn't make things much worse than they already are. A possible workaround would be for sensitive service to create an account just for streaming. Should the password be compromised, there's only a denial of service risk and no further risk. Again, this doesn't help much in the context of desktop app use, as it would have to use it's authenticated user's credentials. Clients just shouldn't send a cleartext password over an unecrypted connection IMO. Marco On May 13, 11:18 am, Marco Kaiser kaiser.ma...@gmail.com wrote: John, this looks pretty interesting! Two questions: 1) you are requiring to send a username and password for Basic Auth - how does that map to apps / services using OAuth, as they won't have access to a user's passwords? (and related, how does this fit into your general roadmap to move everything to OAuth?) 2) the docs only mention http as a protocol, not https. In combination with requiring passwords, only making http available seems quite unsecure. Any plans to also support https soon (or any other mechanism which gives better security?) Thanks, Marco 2009/5/13 John Kalucki jkalu...@gmail.com Chad, Yes, I think this is called POSTDATA in browsers. I don't recall what the actual name of this part of the HTTP protocol is, but it's the body section after the headers
[twitter-dev] Re: New Public Streaming API Resource - Follow
John, this looks pretty interesting! Two questions: 1) you are requiring to send a username and password for Basic Auth - how does that map to apps / services using OAuth, as they won't have access to a user's passwords? (and related, how does this fit into your general roadmap to move everything to OAuth?) 2) the docs only mention http as a protocol, not https. In combination with requiring passwords, only making http available seems quite unsecure. Any plans to also support https soon (or any other mechanism which gives better security?) Thanks, Marco 2009/5/13 John Kalucki jkalu...@gmail.com Chad, Yes, I think this is called POSTDATA in browsers. I don't recall what the actual name of this part of the HTTP protocol is, but it's the body section after the headers. I corrected the file name error. Thanks. -John On May 12, 8:49 pm, Chad Etzel jazzyc...@gmail.com wrote: Hi John, /follow looks very interesting. Since you're asking for feedback I'm copying the follow parameter example documentation: Example: Create a file called 'follow' that contains, exactly and excluding the quotation marks: follow=12 13 15 16 20 87. Execute: curl -d @followinghttp://stream.twitter.com/follow.json -uAnyTwitterUser:Password.You will receive JSON updates from Jack Biz, Crystal, Ev, Krissy, but not from Jeremy, as he's a private user. I'm assuming that follow is just a POSTDATA variable in the normal case (you're just using curl's file posting ability in the example)? In the example, should the file be called following instead of follow (since you are using -d @following in the curl line)? Thanks, -Chad On Tue, May 12, 2009 at 11:24 PM, John Kalucki jkalu...@gmail.com wrote: Note: The Streaming API is currently under a limited alpha test, details below. The /follow Streaming API resource is now publicly available. This resource streams near-real-time public updates posted by an arbitrary set of users. Streaming by user_id may be interesting to a variety of developers who wish to provide a nearly instantaneous experience without the drawbacks of continuous polling, polling rate limits, auto- following and follow limits. For example, a desktop client could simulate a user's /home timeline, minus private updates and mentions, via the /follow resource. Continuous polling would no longer be necessary or desired. Upon receipt of a new streamed message, the REST API may be periodically polled to back-fill mentions, private statuses and other updates not available via the Streaming API. This stream may also be interesting to service developers that follow their subscribers solely to receive their replies or for data mining purposes. Auto-following, following limit and rate limit hassles could be exchanged for real-time streaming subscriber updates. Currently this resource is limited to following 200 user_ids. Developers requiring considerably more followings and/or back-filling via the count parameter should consider applying for the restricted /shadow resource. Feedback is encouraged as we determine the ease-of-use, value, tuning and operational viability of this resource. With any luck, streaming might also be easier on the Twitter service. Our flock of orange whale- hoisting birds are pretty tuckered out. Important Alpha Test Note: The Streaming API (aka Hosebird) is currently under an alpha test. All developers using the Streaming API must tolerate possible unannounced and extended periods of unavailability, especially during off-hours, Pacific Time. New features, resources and policies are being deployed on very little, if any, notice. Any developer may experiment with the unrestricted resources and provide feedback via this list. Access to restricted resources is extremely limited and is only granted on a case-by-case basis after acceptance of an additional terms of service document. Documentation is available: http://apiwiki.twitter.com/Streaming-API-Documentation.
[twitter-dev] Re: API Changes for April 1, 2009
Doug? Anyone? Thanks, Marco 2009/4/9 Marco Kaiser kaiser.ma...@gmail.com I recognize an odd behavior for the following property of embedded user object in the friends timeline (XML format). As I understand from the API docs, following should indicate whether the authenticating user is following the returned user. Obviously, all tweets returned on the /statuses/friends_timeline.xml endpoint should come from users I am following (and I manually verified that for some samples), but still some of them have followingfalse/following set. It seems to be at least consistant in a way that the same user always has the same value set for following in a result set - it just is either always wrong or always right. Is that a known issue? Thanks, Marco 2009/4/5 Martin Dufort martin.duf...@gmail.com I'm seeing inconsitent user attributes within the *same* request for the *same* user. One result has full attributes disclosure, and the other one has not. I've updated Issue 409 with my results. Martin On Apr 2, 8:36 pm, Doug Williams d...@twitter.com wrote: Jeffery, This is valid criticism. This bug came as a surprise to us as well. We otherwise would have given developers fair warning. Unfortunately there is no easy fix, and like a bad heart-break, time may be the only answer. In short, the problem is with the user data cache. To get the extended information into that cache, the user object must either expire or be invalidated through some user initiated update. The expiry on the cache is rather long and you will find that inactive accounts will have abbreviated data for up to 2 weeks. This is obviously sub-optimal, as Matt would say. Doug Williams Twitter API Supporthttp://twitter.com/dougw On Thu, Apr 2, 2009 at 12:27 PM, Jeffrey Greenberg jeffreygreenb...@gmail.com wrote: Doug, Grumble: just to say it, this wasn't handled well at all. The fact that this field disappears whether due to caching or through a coding error has the same result of completely breaking my app. How long will it take for this issue to clear up? Days? How many exactly? and after X days will further requests be populated correctly? thx, jeffrey http://www.tweettronics.com
[twitter-dev] Re: sending DM to all followers?
2009/4/17 Nicole Simon nee...@gmail.com On Fri, Apr 17, 2009 at 12:04 AM, Jesse Stay jesses...@gmail.com wrote: How do I switch off receiving DMs? I get DMs no matter what. I can turn off notifications, but not DMs. Twitter really has not a lot of options. If you do not know how to do that, you obviously never looked. http://twitter.com/account/notifications Uhm... I think you got this completely wrong, as Jesse already pointed out. These settings only control offline notifications via SMS or Email, but they don't make your account stop receiving DMs. It's just plain false what you say here. May I ask what you do on the _developper_ list if you do not even know this much? Hold on - this is an open group, for everyone to share with little or much knowledge about the Twiter API. In fact, one of its main purposes is to give beginners a chance to learn about twitter development. What kind of attitude is it to say you shouldn't be on this list if you don't know about it. It's not a closed circle of professionals, and even if it would be - Jesse would definitely belong in here, as he is a long-time participant and very active developer. I think no one wants to see such behavior here, it's a place to discuss questions about twitter, and not to start flaming other group members. Marco
[twitter-dev] Re: Deprecation of source parameter registration
Why are you deprecating a very important feature for the basic auth method while your OAuth support is still in beta? The last official statement I read about Twitter and OAuth was that it went public, but is still considered beta. Also, if I did not miss an announcement, you were not yet encouraging developers to release OAuth based stuff - has this changed? 2009/4/9 Mobasoft mobat...@gmail.com When I discovered that Twitter used the name from my recetly created app via OAuth, I was pleased. While the turn-around time for manual approval was great, I think that using the data which we've already supplied through the creation of a new OAuth app is the right way to go. Keep up the good work.
[twitter-dev] Re: API Changes for April 1, 2009
I recognize an odd behavior for the following property of embedded user object in the friends timeline (XML format). As I understand from the API docs, following should indicate whether the authenticating user is following the returned user. Obviously, all tweets returned on the /statuses/friends_timeline.xml endpoint should come from users I am following (and I manually verified that for some samples), but still some of them have followingfalse/following set. It seems to be at least consistant in a way that the same user always has the same value set for following in a result set - it just is either always wrong or always right. Is that a known issue? Thanks, Marco 2009/4/5 Martin Dufort martin.duf...@gmail.com I'm seeing inconsitent user attributes within the *same* request for the *same* user. One result has full attributes disclosure, and the other one has not. I've updated Issue 409 with my results. Martin On Apr 2, 8:36 pm, Doug Williams d...@twitter.com wrote: Jeffery, This is valid criticism. This bug came as a surprise to us as well. We otherwise would have given developers fair warning. Unfortunately there is no easy fix, and like a bad heart-break, time may be the only answer. In short, the problem is with the user data cache. To get the extended information into that cache, the user object must either expire or be invalidated through some user initiated update. The expiry on the cache is rather long and you will find that inactive accounts will have abbreviated data for up to 2 weeks. This is obviously sub-optimal, as Matt would say. Doug Williams Twitter API Supporthttp://twitter.com/dougw On Thu, Apr 2, 2009 at 12:27 PM, Jeffrey Greenberg jeffreygreenb...@gmail.com wrote: Doug, Grumble: just to say it, this wasn't handled well at all. The fact that this field disappears whether due to caching or through a coding error has the same result of completely breaking my app. How long will it take for this issue to clear up? Days? How many exactly? and after X days will further requests be populated correctly? thx, jeffrey http://www.tweettronics.com
[twitter-dev] Re: Introducing Doug Williams, Twitter API Support
Congrats Doug! 2009/3/10 Chad Etzel jazzyc...@gmail.com Congrats, Doug! Glad I can finally say that and not spill the beans. We'll miss you on the East Coast; don't be a stranger! -Chad On Mon, Mar 9, 2009 at 6:55 PM, Cameron Kaiser spec...@floodgap.com wrote: Give Doug a warm welcome! Congratulations, Doug! -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- TRUE HEADLINE: Astronaut Takes Blame for Gas in Spacecraft -
