Re: [twitter-dev] Re: Basic Auth Deprecation
marcel (@noradio) and i have been working on http://github.com/marcel/twurl -- there is definitely some work that needs to be done, but we're getting close. On Tue, Apr 13, 2010 at 9:01 PM, TJ Luoma luo...@gmail.com wrote: On Tue, Apr 13, 2010 at 7:35 PM, Raffi Krikorian ra...@twitter.com wrote: we'll make sure to message it long before hand! I'm still unclear what people who use 'curl' will do after basic auth is deprecated. Is there an OAuth for the commandline? If so: pointers, please. TjL -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: New methods for pending follow requests
yeah - this was inherent in my notion when i was saying that we would send you to a twitter.com endpoint. this is similar to how you enable geo right now on a mobile client -- there isn't an API to do it, but there is an API to read the state. the client can send the user to a twitter.com mobile optimized page to switch it on. this is clearly a work in progress, On Tue, Apr 13, 2010 at 6:54 PM, Naveen Ayyagari nav...@getsocialscope.comwrote: I can understand the security issue with providing an endpoint. However, I am not sure there is a lot of value in displaying the information in a client, when the user would then be forced to leave the application, open a browser, possibly login, then click pending requests, then find the user they want to approve from the list they had already been reading, then finally be able to take action to approve or deny. Maybe twitter could consider some providing a url that a client can launch that would take them directly to the approval for a user. Ideally this would work for m.twitter.com and twitter.com Already there is: http://m.twitter.com/friend_requests which asks the user to login and then takes them directly to friend_requests page. However it does not seem to be optimized on m.twitter.com for mobile clients, and is acutally quite unsightly and difficult to navigate on my BlackBerry (The Curve 8310 which is one of the most common BlackBerry models in the wild right now) Maybe friend_requests could be extended to allow something like: http://m.twitter.com/friend_requests/UID or http://m.twitter.com/friend_requests?id=uid This would allow a client to launch a browser and twitter to display a simple accept/reject page directly without much additional user interaction. When browsing on a mobile client, the fewer clicks it takes a user to take a specific action, the more likely they are to engage. Actually, a slightly more complex implementation (maybe overkill), but may provide better user experience: http://m.twitter.com/friend_requests?src_id=uidtarget_id=uid Where src_id is the uid of the user making the request (i.e. if I was using this from my account src_id would be my uid and target_id would be the uid of the user I want to approve or reject). By including the src_id, twitter can determine if there is a current twitter session in the browser and if the src_id is equal to the uid of current session, then a login page may not be required and can skip the login step. Otherwise, just let the user login, then take them directly to the requested approval page. This version simply covers the case where the user is logged in as one user on the website, but as a different user in a client.. As I said, it may be overkill, and may be acceptable to just display an error message if the request is invalid. I think I was clear, but if not feel free to tear apart my assumptions or if there is some security risk I am not considering with this type of implementation? --Naveen Ayyagari @knight9 @SocialScope On Apr 13, 9:06 pm, Raffi Krikorian ra...@twitter.com wrote: Is there API endpoints planned to accept/reject incoming and cancel outgoing pending requests? no - there is not. its following the theory that a malicious client could then accept friend requests to your protected account without your knowledge. I am curious, what the use case is for a list of ids for pending requests? Without APIs to interact with pending requests, what would this information be used for? to display to the end user. for the end user to take action, a twitter client could redirect them to a twitter.com site. For a mobile client, exposing this type of information is valuable to the user, but user objects (not ids) would be required to create a UI for someone to view and then interact with such requests. users/lookup would help with that. -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] chirp questions for non-attendee's
http://www.google.com/moderator/#16/e=5c0f On Tue, Apr 13, 2010 at 22:27, Mathias Herberts mathias.herbe...@gmail.comwrote: On Wed, Apr 14, 2010 at 02:58, Peter Denton petermden...@gmail.com wrote: Thanks to Dewald's advice, I started a new thread for questions those of us not attending chirp could throw out: Why not use Google Moderator for this? People could promote questions so those that interest non attendees the most could be thrown in. http://www.google.com/moderator/#0 Mathias. -- To unsubscribe, reply using remove me as the subject. -- Abraham Williams | Developer for hire | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private.
[twitter-dev] Re: Basic Auth Deprecation
But why is oauth better than basic for a desktop client? i understand it for the webapps but on a desktop client whats the point? Basically you are saying the desktop end user cant be trusted? Sorry but that doesn't make any sense. Please explain. Cheers, Dean On Apr 14, 1:15 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Basic auto being turned off means just that.. Desktop clients can implement xAuth as an alternative, where you do a one-time exchange of login and password for an OAuth access token and continue from there signing your requests and doing things in the OAuth way. You'd no longer, as a best practice and one that I would stress in the upmost even on a desktop client, store the login and password beyond the xAuth access token negotiation step. If the token were revoked you would then query for the login and password again and so on and so on and also and also. Obtaining permission to use xAuth for desktop clients is as easy as sending a well-identified and verbose note to a...@twitter.com. Basic auth had a good run. It's nearly time to say goodnight. Taylor On Tuesday, April 13, 2010, Dean Collins d...@cognation.net wrote: Just so I understand this, applications running on the desktop will still work correct? Basic functionality is only being turned off for web apps correct? It's not like desktop apps will have to start using oauth. Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Tuesday, April 13, 2010 7:31 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Basic Auth Deprecation Could you please announce the hard turn off date somewhere on one of your Twitter blogs about a month ahead of time, so that we all have an official source to point our users to when we explain to them why we're converting everything over to OAuth? On Apr 13, 8:19 pm, Raffi Krikorian ra...@twitter.com wrote: we have announced deprecation, and will hard turn off basic authentication in june. the exact date has not been set, but i presume it will be later in the month. Is Basic Auth going to be deprecated (as in hard switched-off) in June, or are you in June going to announce depracation, with the hard switch-off then coming a few months later? -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject. -- Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod- Hide quoted text - - Show quoted text -
Re: [twitter-dev] Re: Basic Auth Deprecation
in my ideal world, nobody would have access to a user's password except twitter.com -- oauth provides a framework so end applications are not storing the actual password. people are notoriously bad with using the same password on lots of different sites. additionally, oauth provides twitter better visibility into the traffic coming into our system, so we can better shape traffic needs, we can provide auditing back to users on which applications are doing what actions on their behalf, etc. On Wed, Apr 14, 2010 at 5:39 AM, Dean #39;at#39; Cognation dot Net d...@cognation.net wrote: But why is oauth better than basic for a desktop client? i understand it for the webapps but on a desktop client whats the point? Basically you are saying the desktop end user cant be trusted? Sorry but that doesn't make any sense. Please explain. Cheers, Dean On Apr 14, 1:15 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Basic auto being turned off means just that.. Desktop clients can implement xAuth as an alternative, where you do a one-time exchange of login and password for an OAuth access token and continue from there signing your requests and doing things in the OAuth way. You'd no longer, as a best practice and one that I would stress in the upmost even on a desktop client, store the login and password beyond the xAuth access token negotiation step. If the token were revoked you would then query for the login and password again and so on and so on and also and also. Obtaining permission to use xAuth for desktop clients is as easy as sending a well-identified and verbose note to a...@twitter.com. Basic auth had a good run. It's nearly time to say goodnight. Taylor On Tuesday, April 13, 2010, Dean Collins d...@cognation.net wrote: Just so I understand this, applications running on the desktop will still work correct? Basic functionality is only being turned off for web apps correct? It's not like desktop apps will have to start using oauth. Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto: twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Tuesday, April 13, 2010 7:31 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Basic Auth Deprecation Could you please announce the hard turn off date somewhere on one of your Twitter blogs about a month ahead of time, so that we all have an official source to point our users to when we explain to them why we're converting everything over to OAuth? On Apr 13, 8:19 pm, Raffi Krikorian ra...@twitter.com wrote: we have announced deprecation, and will hard turn off basic authentication in june. the exact date has not been set, but i presume it will be later in the month. Is Basic Auth going to be deprecated (as in hard switched-off) in June, or are you in June going to announce depracation, with the hard switch-off then coming a few months later? -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject. -- Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod- Hide quoted text - - Show quoted text - -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] Re: Basic Auth Deprecation
Why are you Twitter guys pushing xAuth so hard? Even for new desktop clients? Instead of recommending a proper oAuth flow with PIN or such? I understood its main purpose is to help legacy clients with transition, and new clients should do proper oAuth. One argument I have seen is that oAuth has usability problems. I would like to see more substance around this statement beyond just developers thinking out loud. I have implemented oAuth in @cremeapp (ok, it uses in-app browser instead of separate, but otherwise it is the proper PIN flow) and not a single person has complained. I see from usage numbers that people breeze through the oAuth authentication just fine. I was expecting worse, but it's fine. It comes down to proper UI design and clarity of instructions. J On Apr 14, 1:15 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Basic auto being turned off means just that.. Desktop clients can implement xAuth as an alternative, where you do a one-time exchange of login and password for an OAuth access token and continue from there signing your requests and doing things in the OAuth way. You'd no longer, as a best practice and one that I would stress in the upmost even on a desktop client, store the login and password beyond the xAuth access token negotiation step. If the token were revoked you would then query for the login and password again and so on and so on and also and also. Obtaining permission to use xAuth for desktop clients is as easy as sending a well-identified and verbose note to a...@twitter.com. Basic auth had a good run. It's nearly time to say goodnight. Taylor On Tuesday, April 13, 2010, Dean Collins d...@cognation.net wrote: Just so I understand this, applications running on the desktop will still work correct? Basic functionality is only being turned off for web apps correct? It's not like desktop apps will have to start using oauth. Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Tuesday, April 13, 2010 7:31 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Basic Auth Deprecation Could you please announce the hard turn off date somewhere on one of your Twitter blogs about a month ahead of time, so that we all have an official source to point our users to when we explain to them why we're converting everything over to OAuth? On Apr 13, 8:19 pm, Raffi Krikorian ra...@twitter.com wrote: we have announced deprecation, and will hard turn off basic authentication in june. the exact date has not been set, but i presume it will be later in the month. Is Basic Auth going to be deprecated (as in hard switched-off) in June, or are you in June going to announce depracation, with the hard switch-off then coming a few months later? -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject. -- Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod
[twitter-dev] Re: Basic Auth Deprecation
I like oAuth because for both Twitter and me as a developer, it associates the request with both the user and app. As a developer, I have a bunch of apps and I can go to twitter.com/oauth to see the number of users that have used each app. (One thing that I noticed - the number goes down sometimes??? Why is that?) Twitter can do things like block rogue apps, analyze popularity easily etc. On Apr 14, 8:58 am, Raffi Krikorian ra...@twitter.com wrote: in my ideal world, nobody would have access to a user's password except twitter.com -- oauth provides a framework so end applications are not storing the actual password. people are notoriously bad with using the same password on lots of different sites. additionally, oauth provides twitter better visibility into the traffic coming into our system, so we can better shape traffic needs, we can provide auditing back to users on which applications are doing what actions on their behalf, etc. On Wed, Apr 14, 2010 at 5:39 AM, Dean #39;at#39; Cognation dot Net d...@cognation.net wrote: But why is oauth better than basic for a desktop client? i understand it for the webapps but on a desktop client whats the point? Basically you are saying the desktop end user cant be trusted? Sorry but that doesn't make any sense. Please explain. Cheers, Dean On Apr 14, 1:15 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Basic auto being turned off means just that.. Desktop clients can implement xAuth as an alternative, where you do a one-time exchange of login and password for an OAuth access token and continue from there signing your requests and doing things in the OAuth way. You'd no longer, as a best practice and one that I would stress in the upmost even on a desktop client, store the login and password beyond the xAuth access token negotiation step. If the token were revoked you would then query for the login and password again and so on and so on and also and also. Obtaining permission to use xAuth for desktop clients is as easy as sending a well-identified and verbose note to a...@twitter.com. Basic auth had a good run. It's nearly time to say goodnight. Taylor On Tuesday, April 13, 2010, Dean Collins d...@cognation.net wrote: Just so I understand this, applications running on the desktop will still work correct? Basic functionality is only being turned off for web apps correct? It's not like desktop apps will have to start using oauth. Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto: twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Tuesday, April 13, 2010 7:31 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Basic Auth Deprecation Could you please announce the hard turn off date somewhere on one of your Twitter blogs about a month ahead of time, so that we all have an official source to point our users to when we explain to them why we're converting everything over to OAuth? On Apr 13, 8:19 pm, Raffi Krikorian ra...@twitter.com wrote: we have announced deprecation, and will hard turn off basic authentication in june. the exact date has not been set, but i presume it will be later in the month. Is Basic Auth going to be deprecated (as in hard switched-off) in June, or are you in June going to announce depracation, with the hard switch-off then coming a few months later? -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject. -- Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod-Hide quoted text - - Show quoted text - -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi
Re: [twitter-dev] Re: Basic Auth Deprecation
- Raffi Krikorian ra...@twitter.com wrote: in my ideal world, nobody would have access to a user's password except twitter.com -- oauth provides a framework so end applications are not storing the actual password. people are notoriously bad with using the same password on lots of different sites. additionally, oauth provides twitter better visibility into the traffic coming into our system, so we can better shape traffic needs, we can provide auditing back to users on which applications are doing what actions on their behalf, etc. Audit trails for users? Hear, hear!! Where is this on the roadmap? I know people who'd love this!!
RE: [twitter-dev] Re: Basic Auth Deprecation
So basically you are saying Twitter wants a chokehold to block apps they don't like which you don't currently have with basic auth. Considering your recent purchase of a twitter client is that really a message you want to be spreading at the moment? How about leaving it up to end users to make the decision about which clients they do and don't use to access twitter. Restricting all clients to oauth only is hardly going to give developers warm and fuzzy feelings that with a single keystroke a client can be banned instantly across the entire ecosystem. Or am I missing something? Cheers, Dean From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Raffi Krikorian Sent: Wednesday, April 14, 2010 8:59 AM To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Re: Basic Auth Deprecation in my ideal world, nobody would have access to a user's password except twitter.com -- oauth provides a framework so end applications are not storing the actual password. people are notoriously bad with using the same password on lots of different sites. additionally, oauth provides twitter better visibility into the traffic coming into our system, so we can better shape traffic needs, we can provide auditing back to users on which applications are doing what actions on their behalf, etc. On Wed, Apr 14, 2010 at 5:39 AM, Dean #39;at#39; Cognation dot Net d...@cognation.net wrote: But why is oauth better than basic for a desktop client? i understand it for the webapps but on a desktop client whats the point? Basically you are saying the desktop end user cant be trusted? Sorry but that doesn't make any sense. Please explain. Cheers, Dean On Apr 14, 1:15 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Basic auto being turned off means just that.. Desktop clients can implement xAuth as an alternative, where you do a one-time exchange of login and password for an OAuth access token and continue from there signing your requests and doing things in the OAuth way. You'd no longer, as a best practice and one that I would stress in the upmost even on a desktop client, store the login and password beyond the xAuth access token negotiation step. If the token were revoked you would then query for the login and password again and so on and so on and also and also. Obtaining permission to use xAuth for desktop clients is as easy as sending a well-identified and verbose note to a...@twitter.com. Basic auth had a good run. It's nearly time to say goodnight. Taylor On Tuesday, April 13, 2010, Dean Collins d...@cognation.net wrote: Just so I understand this, applications running on the desktop will still work correct? Basic functionality is only being turned off for web apps correct? It's not like desktop apps will have to start using oauth. Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Tuesday, April 13, 2010 7:31 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Basic Auth Deprecation Could you please announce the hard turn off date somewhere on one of your Twitter blogs about a month ahead of time, so that we all have an official source to point our users to when we explain to them why we're converting everything over to OAuth? On Apr 13, 8:19 pm, Raffi Krikorian ra...@twitter.com wrote: we have announced deprecation, and will hard turn off basic authentication in june. the exact date has not been set, but i presume it will be later in the month. Is Basic Auth going to be deprecated (as in hard switched-off) in June, or are you in June going to announce depracation, with the hard switch-off then coming a few months later? -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject. -- Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod- Hide quoted text - - Show quoted text - -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Basic Auth Deprecation
Why are you Twitter guys pushing xAuth so hard? Even for new desktop clients? Instead of recommending a proper oAuth flow with PIN or such? I understood its main purpose is to help legacy clients with transition, and new clients should do proper oAuth. I can tell you that there are many TTYtter users, including myself as we speak, who tweet over ssh back to their server. There may not be a browser for them to talk to. There are also users who use it not as a client, but as a command line tool for cron jobs. xAuth, as I understand it, is for the browserless case. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- The steady state of disks is full. -- Ken Thompson - -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: Basic Auth Deprecation
Dean, Basic auth sends the password essentially in the clear (encoded, but trivially so). It's really in everybody's best interest NOT to use basic auth, but to switch to something less sniffable/repeatable. For example, here's a sample credential you're passing to twitter (HTTP header) when you use basic auth: *Authorization: Basic bm9ib2R5OndoYXRldmVy * Go to http://ostermiller.org/calc/encode.html, paste bm9ib2R5OndoYXRldmVy into the box and click Decode next to Base 64. Now you have my password. Sniff some HTTP requests and you've got a whole lot of passwords. Completely non-secure. I'm not even sure why basic auth ever gained any sort of acceptance. Switching off basic auth and onto something like OAuth, any of your users who value their privacy will thank you! 1 for deprecating basic auth. Dan On Wed, Apr 14, 2010 at 9:28 AM, Dean Collins d...@cognation.net wrote: So basically you are saying Twitter wants a chokehold to block apps they don’t like which you don’t currently have with basic auth. Considering your recent purchase of a twitter client is that really a message you want to be spreading at the moment? How about leaving it up to end users to make the decision about which clients they do and don’t use to access twitter. Restricting all clients to oauth only is hardly going to give developers warm and fuzzy feelings that with a single keystroke a client can be banned instantly across the entire ecosystem. Or am I missing something? Cheers, Dean -- *From:* twitter-development-talk@googlegroups.com [mailto: twitter-development-t...@googlegroups.com] *On Behalf Of *Raffi Krikorian *Sent:* Wednesday, April 14, 2010 8:59 AM *To:* twitter-development-talk@googlegroups.com *Subject:* Re: [twitter-dev] Re: Basic Auth Deprecation in my ideal world, nobody would have access to a user's password except twitter.com -- oauth provides a framework so end applications are not storing the actual password. people are notoriously bad with using the same password on lots of different sites. additionally, oauth provides twitter better visibility into the traffic coming into our system, so we can better shape traffic needs, we can provide auditing back to users on which applications are doing what actions on their behalf, etc. On Wed, Apr 14, 2010 at 5:39 AM, Dean #39;at#39; Cognation dot Net d...@cognation.net wrote: But why is oauth better than basic for a desktop client? i understand it for the webapps but on a desktop client whats the point? Basically you are saying the desktop end user cant be trusted? Sorry but that doesn't make any sense. Please explain. Cheers, Dean On Apr 14, 1:15 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Basic auto being turned off means just that.. Desktop clients can implement xAuth as an alternative, where you do a one-time exchange of login and password for an OAuth access token and continue from there signing your requests and doing things in the OAuth way. You'd no longer, as a best practice and one that I would stress in the upmost even on a desktop client, store the login and password beyond the xAuth access token negotiation step. If the token were revoked you would then query for the login and password again and so on and so on and also and also. Obtaining permission to use xAuth for desktop clients is as easy as sending a well-identified and verbose note to a...@twitter.com. Basic auth had a good run. It's nearly time to say goodnight. Taylor On Tuesday, April 13, 2010, Dean Collins d...@cognation.net wrote: Just so I understand this, applications running on the desktop will still work correct? Basic functionality is only being turned off for web apps correct? It's not like desktop apps will have to start using oauth. Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto: twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Tuesday, April 13, 2010 7:31 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Basic Auth Deprecation Could you please announce the hard turn off date somewhere on one of your Twitter blogs about a month ahead of time, so that we all have an official source to point our users to when we explain to them why we're converting everything over to OAuth? On Apr 13, 8:19 pm, Raffi Krikorian ra...@twitter.com wrote: we have announced deprecation, and will hard turn off basic authentication in june. the exact date has not been set, but i presume it will be later in the month. Is Basic Auth going to be deprecated (as in hard switched-off) in June, or are you in June going to announce depracation, with the hard switch-off then coming a few months later? -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi
Re: [twitter-dev] Re: Basic Auth Deprecation
On Wed, Apr 14, 2010 at 8:39 AM, Dean #39;at#39; Cognation dot Net d...@cognation.net wrote: But why is oauth better than basic for a desktop client? i understand it for the webapps but on a desktop client whats the point? Basically you are saying the desktop end user cant be trusted? Sorry but that doesn't make any sense. Please explain. ARGH. Are you kidding me?! Here's a simple use case: Change your Twitter password If you are using only OAuth apps, they will be unaffected. If you are using Basic Auth apps, you will have to go around and update all of them OR risk being locked out of your Twitter account. I know; this just happened to me. More below… On Wed, Apr 14, 2010 at 9:28 AM, Dean Collins d...@cognation.net wrote: So basically you are saying Twitter wants a chokehold to block apps they don’t like which you don’t currently have with basic auth. Considering your recent purchase of a twitter client is that really a message you want to be spreading at the moment? How about leaving it up to end users to make the decision about which clients they do and don’t use to access twitter. Restricting all clients to oauth only is hardly going to give developers warm and fuzzy feelings that with a single keystroke a client can be banned instantly across the entire ecosystem. Or am I missing something? Dean, seriously, lay off the X-Files re-runs. They're making you sound paranoid. Twitter has been talking about this for ***at least*** 6 months, maybe 12. Bringing up the purchase of Tweetie only make it looks like you have an axe to grind. Leave it to end users? Because end users will do what developers will do: the laziest option available. Requiring users to repeatedly type Twitter passwords is going to lead most of them to a) use insecure passwords and b) not change them. Forcing developers who would otherwise be too lazy to implement OAuth to change will make it better for users and developers in the long run. I say this as someone whose ONLY method of interacting with the Twitter API is on the commandline, meaning that I am going to have to look at every single piece of code I've written, every little shell script (several dozen, at least) to see where I have to change things. And I don't make a dime from this, I'm providing a free service. As are — oh yeah — Twitter. Giving away your password is insecure. Twitter users have been extremely vulnerable to this. This will make Twitter accounts more secure. It's a good thing that requires extra work. Changing your password when using Basic Auth is a giant PITA. I know because I just did it across all my Twitter accounts and clients. And anyone who says that Twitter is springing this on people is either a liar or ignorant. TjL -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: Basic Auth Deprecation
again - overly dramatic. everything i said above still stands - it provides transparency into the traffic that applications generate (potentially audit trails for users, better ways to squelch spammy apps, etc.), as well as provides some security in that user's passwords are not being sent in the clear. you can easily look for other examples of people using oauth for similar situations - google is using oauth to allow applications access to mail, etc. So basically you are saying Twitter wants a chokehold to block apps they don’t like which you don’t currently have with basic auth. Considering your recent purchase of a twitter client is that really a message you want to be spreading at the moment? How about leaving it up to end users to make the decision about which clients they do and don’t use to access twitter. Restricting all clients to oauth only is hardly going to give developers warm and fuzzy feelings that with a single keystroke a client can be banned instantly across the entire ecosystem. Or am I missing something? Cheers, Dean -- *From:* twitter-development-talk@googlegroups.com [mailto: twitter-development-t...@googlegroups.com] *On Behalf Of *Raffi Krikorian *Sent:* Wednesday, April 14, 2010 8:59 AM *To:* twitter-development-talk@googlegroups.com *Subject:* Re: [twitter-dev] Re: Basic Auth Deprecation in my ideal world, nobody would have access to a user's password except twitter.com -- oauth provides a framework so end applications are not storing the actual password. people are notoriously bad with using the same password on lots of different sites. additionally, oauth provides twitter better visibility into the traffic coming into our system, so we can better shape traffic needs, we can provide auditing back to users on which applications are doing what actions on their behalf, etc. On Wed, Apr 14, 2010 at 5:39 AM, Dean #39;at#39; Cognation dot Net d...@cognation.net wrote: But why is oauth better than basic for a desktop client? i understand it for the webapps but on a desktop client whats the point? Basically you are saying the desktop end user cant be trusted? Sorry but that doesn't make any sense. Please explain. Cheers, Dean On Apr 14, 1:15 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Basic auto being turned off means just that.. Desktop clients can implement xAuth as an alternative, where you do a one-time exchange of login and password for an OAuth access token and continue from there signing your requests and doing things in the OAuth way. You'd no longer, as a best practice and one that I would stress in the upmost even on a desktop client, store the login and password beyond the xAuth access token negotiation step. If the token were revoked you would then query for the login and password again and so on and so on and also and also. Obtaining permission to use xAuth for desktop clients is as easy as sending a well-identified and verbose note to a...@twitter.com. Basic auth had a good run. It's nearly time to say goodnight. Taylor On Tuesday, April 13, 2010, Dean Collins d...@cognation.net wrote: Just so I understand this, applications running on the desktop will still work correct? Basic functionality is only being turned off for web apps correct? It's not like desktop apps will have to start using oauth. Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto: twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Tuesday, April 13, 2010 7:31 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Basic Auth Deprecation Could you please announce the hard turn off date somewhere on one of your Twitter blogs about a month ahead of time, so that we all have an official source to point our users to when we explain to them why we're converting everything over to OAuth? On Apr 13, 8:19 pm, Raffi Krikorian ra...@twitter.com wrote: we have announced deprecation, and will hard turn off basic authentication in june. the exact date has not been set, but i presume it will be later in the month. Is Basic Auth going to be deprecated (as in hard switched-off) in June, or are you in June going to announce depracation, with the hard switch-off then coming a few months later? -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject. -- Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod- Hide quoted text - - Show quoted text - -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Basic Auth Deprecation
i would love it to :P On Wed, Apr 14, 2010 at 6:18 AM, zn...@comcast.net wrote: - Raffi Krikorian ra...@twitter.com wrote: in my ideal world, nobody would have access to a user's password except twitter.com -- oauth provides a framework so end applications are not storing the actual password. people are notoriously bad with using the same password on lots of different sites. additionally, oauth provides twitter better visibility into the traffic coming into our system, so we can better shape traffic needs, we can provide auditing back to users on which applications are doing what actions on their behalf, etc. Audit trails for users? Hear, hear!! Where is this on the roadmap? I know people who'd love this!! -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: Basic Auth Deprecation
we developed xauth specifically for that - mobile and desktop clients were complaining about usability problems when they have to bounce their users to a web browser. i'm well aware of the implications about xauth, and have blogged about it here: http://mehack.com/xauth-and-perhaps-the-need-for-socializing-ap would love to hear more comments as i formalize my thoughts around this! On Wed, Apr 14, 2010 at 6:15 AM, Jaanus jaa...@gmail.com wrote: Why are you Twitter guys pushing xAuth so hard? Even for new desktop clients? Instead of recommending a proper oAuth flow with PIN or such? I understood its main purpose is to help legacy clients with transition, and new clients should do proper oAuth. One argument I have seen is that oAuth has usability problems. I would like to see more substance around this statement beyond just developers thinking out loud. I have implemented oAuth in @cremeapp (ok, it uses in-app browser instead of separate, but otherwise it is the proper PIN flow) and not a single person has complained. I see from usage numbers that people breeze through the oAuth authentication just fine. I was expecting worse, but it's fine. It comes down to proper UI design and clarity of instructions. J On Apr 14, 1:15 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Basic auto being turned off means just that.. Desktop clients can implement xAuth as an alternative, where you do a one-time exchange of login and password for an OAuth access token and continue from there signing your requests and doing things in the OAuth way. You'd no longer, as a best practice and one that I would stress in the upmost even on a desktop client, store the login and password beyond the xAuth access token negotiation step. If the token were revoked you would then query for the login and password again and so on and so on and also and also. Obtaining permission to use xAuth for desktop clients is as easy as sending a well-identified and verbose note to a...@twitter.com. Basic auth had a good run. It's nearly time to say goodnight. Taylor On Tuesday, April 13, 2010, Dean Collins d...@cognation.net wrote: Just so I understand this, applications running on the desktop will still work correct? Basic functionality is only being turned off for web apps correct? It's not like desktop apps will have to start using oauth. Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto: twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Tuesday, April 13, 2010 7:31 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Basic Auth Deprecation Could you please announce the hard turn off date somewhere on one of your Twitter blogs about a month ahead of time, so that we all have an official source to point our users to when we explain to them why we're converting everything over to OAuth? On Apr 13, 8:19 pm, Raffi Krikorian ra...@twitter.com wrote: we have announced deprecation, and will hard turn off basic authentication in june. the exact date has not been set, but i presume it will be later in the month. Is Basic Auth going to be deprecated (as in hard switched-off) in June, or are you in June going to announce depracation, with the hard switch-off then coming a few months later? -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject. -- Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Basic Auth Deprecation
xauth is definitely useful for the browserless case. On Wed, Apr 14, 2010 at 6:33 AM, Cameron Kaiser spec...@floodgap.comwrote: Why are you Twitter guys pushing xAuth so hard? Even for new desktop clients? Instead of recommending a proper oAuth flow with PIN or such? I understood its main purpose is to help legacy clients with transition, and new clients should do proper oAuth. I can tell you that there are many TTYtter users, including myself as we speak, who tweet over ssh back to their server. There may not be a browser for them to talk to. There are also users who use it not as a client, but as a command line tool for cron jobs. xAuth, as I understand it, is for the browserless case. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- The steady state of disks is full. -- Ken Thompson - -- To unsubscribe, reply using remove me as the subject. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
RE: [twitter-dev] Re: Basic Auth Deprecation
Raffi, Twitter (corporate) are hardly in a position to start demanding the rights to kill client apps at the moment. But the sheep will head off to the slaughter without realizing whats happening to them as they go. I think it's time for me to pass on developing twitter apps. Anyone who wants to make me an offer for www.MyPostButler.com http://www.mypostbutler.com/ can do so now otherwise I'll be putting it up for sale on one of the auction sites by Friday. Cheers, Dean From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Raffi Krikorian Sent: Wednesday, April 14, 2010 10:08 AM To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Re: Basic Auth Deprecation again - overly dramatic. everything i said above still stands - it provides transparency into the traffic that applications generate (potentially audit trails for users, better ways to squelch spammy apps, etc.), as well as provides some security in that user's passwords are not being sent in the clear. you can easily look for other examples of people using oauth for similar situations - google is using oauth to allow applications access to mail, etc. So basically you are saying Twitter wants a chokehold to block apps they don't like which you don't currently have with basic auth. Considering your recent purchase of a twitter client is that really a message you want to be spreading at the moment? How about leaving it up to end users to make the decision about which clients they do and don't use to access twitter. Restricting all clients to oauth only is hardly going to give developers warm and fuzzy feelings that with a single keystroke a client can be banned instantly across the entire ecosystem. Or am I missing something? Cheers, Dean From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Raffi Krikorian Sent: Wednesday, April 14, 2010 8:59 AM To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Re: Basic Auth Deprecation in my ideal world, nobody would have access to a user's password except twitter.com -- oauth provides a framework so end applications are not storing the actual password. people are notoriously bad with using the same password on lots of different sites. additionally, oauth provides twitter better visibility into the traffic coming into our system, so we can better shape traffic needs, we can provide auditing back to users on which applications are doing what actions on their behalf, etc. On Wed, Apr 14, 2010 at 5:39 AM, Dean #39;at#39; Cognation dot Net d...@cognation.net wrote: But why is oauth better than basic for a desktop client? i understand it for the webapps but on a desktop client whats the point? Basically you are saying the desktop end user cant be trusted? Sorry but that doesn't make any sense. Please explain. Cheers, Dean On Apr 14, 1:15 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Basic auto being turned off means just that.. Desktop clients can implement xAuth as an alternative, where you do a one-time exchange of login and password for an OAuth access token and continue from there signing your requests and doing things in the OAuth way. You'd no longer, as a best practice and one that I would stress in the upmost even on a desktop client, store the login and password beyond the xAuth access token negotiation step. If the token were revoked you would then query for the login and password again and so on and so on and also and also. Obtaining permission to use xAuth for desktop clients is as easy as sending a well-identified and verbose note to a...@twitter.com. Basic auth had a good run. It's nearly time to say goodnight. Taylor On Tuesday, April 13, 2010, Dean Collins d...@cognation.net wrote: Just so I understand this, applications running on the desktop will still work correct? Basic functionality is only being turned off for web apps correct? It's not like desktop apps will have to start using oauth. Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent:
RE: [twitter-dev] Re: Basic Auth Deprecation
If an app is trusted enough to have xAuth access, it should have the ability to do things like accept and reject followers for protected accounts via the API. An malicious xAuth application would already have full access to the user's account so it could already accept/reject followers through other means. It's the same with creating an account-there's no security justification for disallowing creating accounts for xAuth applications when the account settings are already available to xAuth applications that choose not to follow the rules and restrictions. Perhaps xAuth access should be granted only to people that have been authenticated with a high level of assurance-the same method you use for verified accounts and/or through some high-assurance certificate provider. For example, you could require xAuth developers to sign a token using their iPhone appstore/Symbian Signed/WinMo/Java Verified/High Assurance SSL certificate in order to prove their identities. And/or, charge a token amount of money for xAuth access so that you can verify identity somewhat via the credit card used. The problem with socializing security like you suggested is that it can only detect what end-users can detect. Chances are that all the users of a mythical Bieber Ponies application are going to be relatively unsophisticated people that couldn't care less about security. And, also a malicious application can keep its bad behavior dormant for a long time until it builds up a large userbase and/or until some software update activates the bad behavior. -Brian From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Raffi Krikorian Sent: Wednesday, April 14, 2010 9:09 AM To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Re: Basic Auth Deprecation we developed xauth specifically for that - mobile and desktop clients were complaining about usability problems when they have to bounce their users to a web browser. i'm well aware of the implications about xauth, and have blogged about it here: http://mehack.com/xauth-and-perhaps-the-need-for-socializing-ap would love to hear more comments as i formalize my thoughts around this! On Wed, Apr 14, 2010 at 6:15 AM, Jaanus jaa...@gmail.com wrote: Why are you Twitter guys pushing xAuth so hard? Even for new desktop clients? Instead of recommending a proper oAuth flow with PIN or such? I understood its main purpose is to help legacy clients with transition, and new clients should do proper oAuth. One argument I have seen is that oAuth has usability problems. I would like to see more substance around this statement beyond just developers thinking out loud. I have implemented oAuth in @cremeapp (ok, it uses in-app browser instead of separate, but otherwise it is the proper PIN flow) and not a single person has complained. I see from usage numbers that people breeze through the oAuth authentication just fine. I was expecting worse, but it's fine. It comes down to proper UI design and clarity of instructions. J On Apr 14, 1:15 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Basic auto being turned off means just that.. Desktop clients can implement xAuth as an alternative, where you do a one-time exchange of login and password for an OAuth access token and continue from there signing your requests and doing things in the OAuth way. You'd no longer, as a best practice and one that I would stress in the upmost even on a desktop client, store the login and password beyond the xAuth access token negotiation step. If the token were revoked you would then query for the login and password again and so on and so on and also and also. Obtaining permission to use xAuth for desktop clients is as easy as sending a well-identified and verbose note to a...@twitter.com. Basic auth had a good run. It's nearly time to say goodnight. Taylor On Tuesday, April 13, 2010, Dean Collins d...@cognation.net wrote: Just so I understand this, applications running on the desktop will still work correct? Basic functionality is only being turned off for web apps correct? It's not like desktop apps will have to start using oauth. Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Tuesday, April 13, 2010 7:31 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Basic Auth Deprecation Could you please announce the hard turn off date somewhere on one of your Twitter blogs about a month ahead of time, so that we all have an official source to point our users to when we explain to them why we're converting everything over to OAuth? On Apr 13, 8:19 pm, Raffi Krikorian ra...@twitter.com wrote: we have announced deprecation, and will hard turn off basic authentication in june. the exact date has not been set, but i
Re: [twitter-dev] Re: Basic Auth Deprecation
Response inline. On Wed, Apr 14, 2010 at 7:07 AM, Raffi Krikorian ra...@twitter.com wrote: again - overly dramatic. everything i said above still stands - it provides transparency into the traffic that applications generate (potentially audit trails for users, better ways to squelch spammy apps, etc.), as well as provides some security in that user's passwords are not being sent in the clear. you can easily look for other examples of people using oauth for similar situations - google is using oauth to allow applications access to mail, etc. For what it's worth: Speaking as a Googler, and as someone who is interested in user's safety and security overall, I'm thrilled to see the industry trend toward deprecation of stored credentials in favor of delegated authorization mechanisms. So thank you — on behalf of the industry — to Twitter for doing this. It's difficult/impossible to ensure the long-term safety and security of stored passwords required for standard basic auth, and it is similarly impossible to know for sure that a desktop application is either a) really a desktop application or b) really secure. A delegated authorization flow has the advantage in that it can be scoped to grant only specific narrow permissions (read twitter messages, read a calendar, check your email), but not others (delete your account, charge your credit card, read your web history, etc).Plus, authorization tokens can be revoked on a per-application basis on the server side if a third-party application goes rogue or is compromised in the future (or set to automatically expire). None of those things are easily possible with the traditional master key approach of stored passwords. While there are several evolving ways to get there — and I don't think we've collectively quite figured it all out yet (Raffi's post thinking about trust models for xauth is right on) — the general message of deprecating usernames and passwords in third-party apps is the right one for all of us, so I still applaud Twitter for taking a stand here, and expect and hope many others will follow. -DeWitt So basically you are saying Twitter wants a chokehold to block apps they don’t like which you don’t currently have with basic auth. Considering your recent purchase of a twitter client is that really a message you want to be spreading at the moment? How about leaving it up to end users to make the decision about which clients they do and don’t use to access twitter. Restricting all clients to oauth only is hardly going to give developers warm and fuzzy feelings that with a single keystroke a client can be banned instantly across the entire ecosystem. Or am I missing something? Cheers, Dean -- *From:* twitter-development-talk@googlegroups.com [mailto: twitter-development-t...@googlegroups.com] *On Behalf Of *Raffi Krikorian *Sent:* Wednesday, April 14, 2010 8:59 AM *To:* twitter-development-talk@googlegroups.com *Subject:* Re: [twitter-dev] Re: Basic Auth Deprecation in my ideal world, nobody would have access to a user's password except twitter.com -- oauth provides a framework so end applications are not storing the actual password. people are notoriously bad with using the same password on lots of different sites. additionally, oauth provides twitter better visibility into the traffic coming into our system, so we can better shape traffic needs, we can provide auditing back to users on which applications are doing what actions on their behalf, etc. On Wed, Apr 14, 2010 at 5:39 AM, Dean #39;at#39; Cognation dot Net d...@cognation.net wrote: But why is oauth better than basic for a desktop client? i understand it for the webapps but on a desktop client whats the point? Basically you are saying the desktop end user cant be trusted? Sorry but that doesn't make any sense. Please explain. Cheers, Dean On Apr 14, 1:15 am, Taylor Singletary taylorsinglet...@twitter.com wrote: Basic auto being turned off means just that.. Desktop clients can implement xAuth as an alternative, where you do a one-time exchange of login and password for an OAuth access token and continue from there signing your requests and doing things in the OAuth way. You'd no longer, as a best practice and one that I would stress in the upmost even on a desktop client, store the login and password beyond the xAuth access token negotiation step. If the token were revoked you would then query for the login and password again and so on and so on and also and also. Obtaining permission to use xAuth for desktop clients is as easy as sending a well-identified and verbose note to a...@twitter.com. Basic auth had a good run. It's nearly time to say goodnight. Taylor On Tuesday, April 13, 2010, Dean Collins d...@cognation.net wrote: Just so I understand this, applications running on the desktop will still work correct?
[twitter-dev] Re: Basic Auth Deprecation
OAuth has benefits all around for everybody. In addition to the benefits already mentioned: 1) For a web app like mine, it saves a TON of support workload with people who change their Twitter password, don't change it in my system, and then blame my system for not working because it's not able to access their Twitter account. 2) If your app has its own API, you'll quickly understand the need for OAuth and some form of control over the services that access your API. I just haven't had the time to put an OAuth server on my own API (have been too busy taking down my Christmas decorations these past week or three), but it's coming. You really get annoyed when spammers cram their crap into your system via ip-hopping proxies, and there's very little you can do about it apart from finding the shit and deleting it afterwards. -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Streaming API - weird data in JSON text
Can someone please tell me why some tweets have the following as the text? text:\uc624\ub298 \uc2dc\uac00\ucd1d\uc561\uc774 $AAPL \uc740 $208.0B \uc774\uace0 $GOOG \uc740 $177.2B \ub124\uc694. \uadf8\ub3d9\uc548 \uc5c5\uce58\ub77d \ub4a4\uce58\ub77d\ud558\ub358 \ub450 \ud68c\uc0ac\uc758 \uc2dc\uac00\ucd1d\uc561 \uacbd\uc7c1\uc740 \uc544\uc774\ud328\ub4dc \ubc1c\ud45c\ub97c \uc804\ud6c4\ud574\uc11c \uc560\ud50c \ucabd\uc73c\ub85c \uae30\uc6b0\ub294 \uac83 \uac19\uc2b5\ub2c8\ub2e4. \ubb3c\ub860 \ud5a5\ud6c4\uc5d0 \uc5b4\ub5bb \uac8c \ub420\uc9c... Thanks, Peter
Re: [twitter-dev] Re: Basic Auth Deprecation
OAuth was intended to facilitate inter-platform user account access without requiring actual usernames or passwords to be exchanged. This would allow platforms such as Twitter, Facebook, TwitPic, etc. to access each others user accounts while maintaining the privacy of that user's access credentials. Requiring OAuth for end-user client applications is somewhat of a misapplication of its intended purpose. Client apps aren't separate platforms, but extensions of the target platform. User credentials aren't being shared, but simply provided to the target platform (Twitter). No one but the user, his device's client, and Twitter are involved, and all three are trusted participants in the access credential exchange process. However, OAuth does provide some valuable side benefits such as application tracking, accounting, and control, and XAuth hides the cumbersomeness of exiting to a browser and retrieving and entering a PIN. XAuth simply makes the assumption that the end-user's Twitter client is at least as trustworthy as the end-user's web browser. As far as not storing actual username / password credentials in the client, that is neither here nor there with regards to OAuth. Practically every browser made offers to store your user access credentials when they recognize a user access authentication transaction. A user is free to record their access credentials anyway they want. The OAuth specification takes no stand on this, as it shouldn't. It's important to note that OAuth does not actually improve user credential security, or security of their accounts. It in fact opens the user up to phishing attacks with bogus challenges requesting access to sites to obtain their actual user credentials to those sites. Users could easily be lulled into providing this information without too much hesitation as they grow accustomed to this required practice with the apps they use. Personally, I think requiring OAuth for client apps serves little purpose since these apps collectively represent such a small part of Twitter's total traffic. It does however unnecessarily complicate the user access process to their accounts and could eventually compromise their account security. The claims that Basic Auth is insecure are totally false. Basic Auth when transmitted via https is quite secure. Millions of username/password credentials are securely exchanged over https everyday, including Twitter itself when accessed via the Twitter web client (I may be wrong, but I don't believe Twitter's own web client uses OAuth). On Wed, Apr 14, 2010 at 8:33 AM, Cameron Kaiser spec...@floodgap.comwrote: Why are you Twitter guys pushing xAuth so hard? Even for new desktop clients? Instead of recommending a proper oAuth flow with PIN or such? I understood its main purpose is to help legacy clients with transition, and new clients should do proper oAuth. I can tell you that there are many TTYtter users, including myself as we speak, who tweet over ssh back to their server. There may not be a browser for them to talk to. There are also users who use it not as a client, but as a command line tool for cron jobs. xAuth, as I understand it, is for the browserless case. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- The steady state of disks is full. -- Ken Thompson - -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Streaming API - weird data in JSON text
Unicode? http://json.org/ -josh 2010/4/14 Mad Euchre mad.ukrain...@gmail.com: Can someone please tell me why some tweets have the following as the text? text:\uc624\ub298 \uc2dc\uac00\ucd1d\uc561\uc774 $AAPL \uc740 $208.0B \uc774\uace0 $GOOG \uc740 $177.2B \ub124\uc694. \uadf8\ub3d9\uc548 \uc5c5\uce58\ub77d \ub4a4\uce58\ub77d\ud558\ub358 \ub450 \ud68c\uc0ac\uc758 \uc2dc\uac00\ucd1d\uc561 \uacbd\uc7c1\uc740 \uc544\uc774\ud328\ub4dc \ubc1c\ud45c\ub97c \uc804\ud6c4\ud574\uc11c \uc560\ud50c \ucabd\uc73c\ub85c \uae30\uc6b0\ub294 \uac83 \uac19\uc2b5\ub2c8\ub2e4. \ubb3c\ub860 \ud5a5\ud6c4\uc5d0 \uc5b4\ub5bb \uac8c \ub420\uc9c... Thanks, Peter -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: Basic Auth Deprecation
We're getting ready to release a few changes to our oauth implementation that will allow two legged oauth for public methods. On Apr 14, 2010, at 9:16 AM, Lil Peck lilp...@gmail.com wrote: On Tue, Apr 13, 2010 at 11:01 PM, TJ Luoma luo...@gmail.com wrote: I'm still unclear what people who use 'curl' will do after basic auth is deprecated. Likewise for those of us who have Classic ASP web apps that use XMLHTTP (http://asp.web.id/update-twitter-status-with-classic-asp-vbscript.html )! Will 2 legged Oauth work for us? When will Twitter offer that? Will it be as simple to integrate as is basic authentication? -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: chirp questions for non-attendee's
I'm one of the Brians on Twitter's API Policy team, and we're going to be participating in an API Policy panel with @delbius on the second day of Chirp. We have our own Google Moderator page set up for this (accessible from the link Abraham sent out, but here also for good measure): http://bit.ly/chirppolicy . Please add your questions here and we'll answer them at the panel, as well as post a recap for you here. Thanks, Brian Sutorius On Apr 14, 12:59 am, Abraham Williams 4bra...@gmail.com wrote: http://www.google.com/moderator/#16/e=5c0f -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Streaming API - weird data in JSON text
2010/4/14 Mad Euchre mad.ukrain...@gmail.com: Can someone please tell me why some tweets have the following as the text? text:\uc624\ub298 \uc2dc\uac00\ucd1d\uc561\uc774 $AAPL \uc740 $208.0B \uc774\uace0 $GOOG \uc740 $177.2B \ub124\uc694. \uadf8\ub3d9\uc548 \uc5c5\uce58\ub77d \ub4a4\uce58\ub77d\ud558\ub358 \ub450 \ud68c\uc0ac\uc758 \uc2dc\uac00\ucd1d\uc561 \uacbd\uc7c1\uc740 \uc544\uc774\ud328\ub4dc \ubc1c\ud45c\ub97c \uc804\ud6c4\ud574\uc11c \uc560\ud50c \ucabd\uc73c\ub85c \uae30\uc6b0\ub294 \uac83 \uac19\uc2b5\ub2c8\ub2e4. \ubb3c\ub860 \ud5a5\ud6c4\uc5d0 \uc5b4\ub5bb \uac8c \ub420\uc9c... Thanks, Peter Because not everyone speaks English and ASCII. ∞ Andy Badera ∞ +1 518-641-1280 Google Voice ∞ This email is: [ ] bloggable [x] ask first [ ] private ∞ Google me: http://www.google.com/search?q=andrew%20badera -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] User Streams API
From John's announcement: User streams permissions are not tuned for service-to-service integration, rather they are tuned for end-user-display applications. Needless to say, it is a big disappointment that the user streams API is not available for services, but only for desktop apps. I could have saved me (and others) much processing, and eliminated a lot of delays, in certain aspects of the services that we provide to users. -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] User Streams API
Dewalt, We can't do everything at once. We can't release everything at once. We have to pick the biggest return features, then let the features trickle down where possible. Everything in user streams can be applied to service streams in good time, but there are privacy issues and some tricky scale issue to be sorted out before we can do service integrations on much of this data. This feature couldn't have saved you any effort -- it hasn't even been released yet. We're in a preview period way way out in front of launch. This was clear in my doc. We're giving you long range guidance. Seriously. -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Wed, Apr 14, 2010 at 12:08 PM, Dewald Pretorius dpr...@gmail.com wrote: From John's announcement: User streams permissions are not tuned for service-to-service integration, rather they are tuned for end-user-display applications. Needless to say, it is a big disappointment that the user streams API is not available for services, but only for desktop apps. I could have saved me (and others) much processing, and eliminated a lot of delays, in certain aspects of the services that we provide to users. -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: User Streams API
John, My apologies. I should have said, would have. English is my second language. It will be great if user streams are going to be available to services at some point in the near future. Specifically, real-time notification of social graph changes. If that's on your road map, then please say so. Because, in your long range guidance, what was said was simply that user streams are not available to services. On Apr 14, 4:22 pm, John Kalucki j...@twitter.com wrote: Dewalt, We can't do everything at once. We can't release everything at once. We have to pick the biggest return features, then let the features trickle down where possible. Everything in user streams can be applied to service streams in good time, but there are privacy issues and some tricky scale issue to be sorted out before we can do service integrations on much of this data. This feature couldn't have saved you any effort -- it hasn't even been released yet. We're in a preview period way way out in front of launch. This was clear in my doc. We're giving you long range guidance. Seriously. -John Kaluckihttp://twitter.com/jkalucki Infrastructure, Twitter Inc. On Wed, Apr 14, 2010 at 12:08 PM, Dewald Pretorius dpr...@gmail.com wrote: From John's announcement: User streams permissions are not tuned for service-to-service integration, rather they are tuned for end-user-display applications. Needless to say, it is a big disappointment that the user streams API is not available for services, but only for desktop apps. I could have saved me (and others) much processing, and eliminated a lot of delays, in certain aspects of the services that we provide to users. -- To unsubscribe, reply using remove me as the subject.- Hide quoted text - - Show quoted text -
Re: [twitter-dev] User Streams API
John, A question - what is the line between user/desktop apps and services? A few random ideas - not sure if any of these exist or not: 1) An app which uses the new stream services to monitor every tweet by folks you follow (plus everything else in the streams) and triggers specific actions on tweets that match some complex set of criteria (so more than the search apis could handle - something like the tenth person to tweet a given phrase or forward just tweets from folks on my partners List which mention my product to me immediately etc (you can I'm sure come up with many other more complex examples - basically think advanced return of the long gone TRACK feature - but initially perhaps limited to just accounts you follow) What would be, from Twitter's perspective, the difference between if this app ran on a desktop computer vs ran on a server in a data center somewhere? (is it just that the server probably would run this same app on behalf of multiple other accounts?) 2) An app which monitors content from multiple different Twitter accounts (all authenticated via Oauth) and might, for example, route messages to a single place - useful perhaps if you have multiple Twitter accounts to handle common mispellings of your company name or to represent different divisions of the company etc but want to say consolidate all @reply messages to any one of your accounts to a single place - your CRMlike systems for example Either of these apps could, potentially, run on a desktop computer with a stable internet connection work forward their results to other computers across the web. Or these could run on a server somewhere in the cloud. Or they could run on a virtual computer in the cloud and i don't exactly see how Twitter would differentiate those cases (other than say if the same IP address was servicing lots of accounts - but I can see desktop client needs to handle more than one account at the same time) Shannon (sorry I'm not at Chirp missed the registration deadline for the hackday tonight) cell: 1.510.333.0295 Twitter - rycaut Pearltrees - http://www.pearltrees.com/rycaut/ Blogs: Slow Brand - http://slowbrand.com Searching for the Moon - http://shannonclark.wordpress.com On Wed, Apr 14, 2010 at 12:22 PM, John Kalucki j...@twitter.com wrote: Dewalt, We can't do everything at once. We can't release everything at once. We have to pick the biggest return features, then let the features trickle down where possible. Everything in user streams can be applied to service streams in good time, but there are privacy issues and some tricky scale issue to be sorted out before we can do service integrations on much of this data. This feature couldn't have saved you any effort -- it hasn't even been released yet. We're in a preview period way way out in front of launch. This was clear in my doc. We're giving you long range guidance. Seriously. -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Wed, Apr 14, 2010 at 12:08 PM, Dewald Pretorius dpr...@gmail.com wrote: From John's announcement: User streams permissions are not tuned for service-to-service integration, rather they are tuned for end-user-display applications. Needless to say, it is a big disappointment that the user streams API is not available for services, but only for desktop apps. I could have saved me (and others) much processing, and eliminated a lot of delays, in certain aspects of the services that we provide to users. -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Annotation details
Just curious if there is any documentation on how annotations will be implemented? Any ideas on size limitations or restrictions for this meta data? -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] dev.twitter.com
Okay, this seriously rocks. Congrats to everyone who worked on making dev.twitter.com happen. -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Infochimps Datasets available for Hack Day: drawn from 1.6B tweets, 40M+ users+reputation, ~0.5B reply links, more!
Hi all, I'm pleased to announce that Infochimps is making datasets from our massive scrape of the Twitter corpus available for Chirp Hack day devs. There's a big opportunity for apps that draw on the historical record and *structure* of twitter -- apps that require a global perspective and intense computation. The following are available to mash up against other datasets from infochimps.org or even just to bootstrap-seed the database for your Hack Day application. We also have a 30-machine cluster up to do further extractions, so if you have something really interesting you'd like to pull please let me know. *Reputation Metrics from Reply and Follow graph*s Uses algorithm similar to pagerank to derive reputation, one using the a_follows_b graph and one using the a_replies_b graphs *Reply/retweet/mention graph* Every observed Reply, retweet, or mention seen in a 1.6B-tweet sample (about 15% of historical record): a_[rel]_b, user_a_id, user_b_id, tweet_id *Twitter Users by Background Color* The number of users with each background color: color code, user count *Twitter Users by Friends Count *The number of users with a given number of friends: number of friends, user count *Twitter Users by Followers Count* The number of users with a given number of followers: number of followers, user count *Twitter Users by Created At* The number of users whose accounts were created in a given month/day/hour along with the earliest seen ID in that hour: timestamp to month/day/hour, user count *Smileys* Smiley faces with user, date, tweet_id *Hashtags* Hashtags with user, date, tweet_id *TweetUrl* URLs with user, date, tweet_id *Twitter Users by Location* The number of users in a location string (as provided by the user in their profile). location, user count *Stock Tweets* Tweets that include the stock symbol tag convention of $STOCKNAME or $$. The tweet is listed for each time a tag is used in the tweet. stock_tweet (resource name), symbol captured, tweet object (all things in a tweet) *Stock Prices *Daily stock prices for the NASDAQ, NYSE, AMEX exchanges 1970-now symbol, open, low, close, high, volume Parameters for what's available: raw object size number of objs a_follows_b 45.8 GB 1,587,838,568 a_mentions_b29.5 GB 493,682,309 a_retweets_b 1.6 GB36,022,061 twitter_user 3.1 GB43,261,388 tweets 376.0 GB 1,641,624,381 hashtag 7.1 GB 139,916,844 smiley 4.4 GB99,272,082 tweet_url 29.5 GB 433,278,116 If you'd like access to any of these, or have an idea that needs something /not/ here, please let me know (f...@infochimps.org). We're only opening access to Hack Day devs for now -- but please let us know your ideas so we can show twitter how much demand there is for aggregated access to data. best, flip @mrflip 512-659-6846 http://infochimps.org Find any dataset in the world -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] dev.twitter.com
+1... this is nice. On Wed, Apr 14, 2010 at 4:27 PM, Dewald Pretorius dpr...@gmail.com wrote: Okay, this seriously rocks. Congrats to everyone who worked on making dev.twitter.com happen. -- To unsubscribe, reply using remove me as the subject. -- Regards, Atul Kulkarni
Re: [twitter-dev] dev.twitter.com
cool - thanks - taylor has been spending a lot of time behind the scenes pushing this forward. he has always felt that having this portal was extremely important for developers, and he made it happen. On Wed, Apr 14, 2010 at 2:38 PM, Atul Kulkarni atulskulka...@gmail.comwrote: +1... this is nice. On Wed, Apr 14, 2010 at 4:27 PM, Dewald Pretorius dpr...@gmail.comwrote: Okay, this seriously rocks. Congrats to everyone who worked on making dev.twitter.com happen. -- To unsubscribe, reply using remove me as the subject. -- Regards, Atul Kulkarni -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Annotation details
we will be releasing data in due time! On Wed, Apr 14, 2010 at 2:05 PM, James Teters jtet...@gmail.com wrote: Just curious if there is any documentation on how annotations will be implemented? Any ideas on size limitations or restrictions for this meta data? -- To unsubscribe, reply using remove me as the subject. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] dev.twitter.com
Thanks for the positive feedback! We're working hard on making this always the most up to date resource as possible -- admittedly, there's still some work to do to get everything in agreement with the dynamic world of the wiki. Look for much more to come on this portal. It's going to keep getting more awesome! Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Wed, Apr 14, 2010 at 2:49 PM, Raffi Krikorian ra...@twitter.com wrote: cool - thanks - taylor has been spending a lot of time behind the scenes pushing this forward. he has always felt that having this portal was extremely important for developers, and he made it happen. On Wed, Apr 14, 2010 at 2:38 PM, Atul Kulkarni atulskulka...@gmail.comwrote: +1... this is nice. On Wed, Apr 14, 2010 at 4:27 PM, Dewald Pretorius dpr...@gmail.comwrote: Okay, this seriously rocks. Congrats to everyone who worked on making dev.twitter.com happen. -- To unsubscribe, reply using remove me as the subject. -- Regards, Atul Kulkarni -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] dev.twitter.com
Yeah, very nice work team. Thanks for doing this. On Wed, Apr 14, 2010 at 2:52 PM, Taylor Singletary taylorsinglet...@twitter.com wrote: Thanks for the positive feedback! We're working hard on making this always the most up to date resource as possible -- admittedly, there's still some work to do to get everything in agreement with the dynamic world of the wiki. Look for much more to come on this portal. It's going to keep getting more awesome! Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Wed, Apr 14, 2010 at 2:49 PM, Raffi Krikorian ra...@twitter.comwrote: cool - thanks - taylor has been spending a lot of time behind the scenes pushing this forward. he has always felt that having this portal was extremely important for developers, and he made it happen. On Wed, Apr 14, 2010 at 2:38 PM, Atul Kulkarni atulskulka...@gmail.comwrote: +1... this is nice. On Wed, Apr 14, 2010 at 4:27 PM, Dewald Pretorius dpr...@gmail.comwrote: Okay, this seriously rocks. Congrats to everyone who worked on making dev.twitter.com happen. -- To unsubscribe, reply using remove me as the subject. -- Regards, Atul Kulkarni -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] dev.twitter.com
Awesome !! Nice work . On Wed, Apr 14, 2010 at 5:00 PM, Peter Denton petermden...@gmail.comwrote: Yeah, very nice work team. Thanks for doing this. On Wed, Apr 14, 2010 at 2:52 PM, Taylor Singletary taylorsinglet...@twitter.com wrote: Thanks for the positive feedback! We're working hard on making this always the most up to date resource as possible -- admittedly, there's still some work to do to get everything in agreement with the dynamic world of the wiki. Look for much more to come on this portal. It's going to keep getting more awesome! Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Wed, Apr 14, 2010 at 2:49 PM, Raffi Krikorian ra...@twitter.comwrote: cool - thanks - taylor has been spending a lot of time behind the scenes pushing this forward. he has always felt that having this portal was extremely important for developers, and he made it happen. On Wed, Apr 14, 2010 at 2:38 PM, Atul Kulkarni atulskulka...@gmail.comwrote: +1... this is nice. On Wed, Apr 14, 2010 at 4:27 PM, Dewald Pretorius dpr...@gmail.comwrote: Okay, this seriously rocks. Congrats to everyone who worked on making dev.twitter.com happen. -- To unsubscribe, reply using remove me as the subject. -- Regards, Atul Kulkarni -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] dev.twitter.com
Very nice! RIP apiwiki. Josh
Re: [twitter-dev] dev.twitter.com
we'll get there soon :P On Wed, Apr 14, 2010 at 3:16 PM, Josh Roesslein jroessl...@gmail.comwrote: Very nice! RIP apiwiki. Josh -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: dev.twitter.com
Why in peace? :P +1 on the positive sentiments. Looks great! --Robby On Apr 14, 3:16 pm, Josh Roesslein jroessl...@gmail.com wrote: Very nice! RIP apiwiki. Josh -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: Basic Auth Deprecation
I am all for oAuth replacing basic, but one of the remaining issues is consumer keys. With 1.0 signing is required thus requiring distributing keys with your application. We all know this is pretty unsafe since any hacker could yank them out. oAuth 2.0 does seem to solve a lot of the issues involving desktop applications, but is still being drafted. So maybe holding off basic auth depreciation until then might not be ideal, but I think it would help make porting to oAuth a bit easier. Just curious how soon can we expect 2.0 to be rolling out and if Twitter has considered at all extending basic auth's lifetime. Thanks, Josh
Re: [twitter-dev] Re: Basic Auth Deprecation
yes, it could be a problem - however, there are known solutions to obfuscating and keeping your consumer key secret. not perfect, but pretty good. maybe we can start a discussion around this? people are going to need to start to move towards this method, and we are here to help you if you need it. ps. DO NOT COUNT ON THIS, but @anywhere is powered using a draft oauth 2.0 spec. we are not yet opening up those endpoints for public use because we reserve the right to switch them around to follow the spec a bit more closely. we will be opening this up for others to use, but we do not yet have a timeframe for it. we have to first fully deploy our oauth 1.0a rewrite. On Wed, Apr 14, 2010 at 3:22 PM, Josh Roesslein jroessl...@gmail.comwrote: I am all for oAuth replacing basic, but one of the remaining issues is consumer keys. With 1.0 signing is required thus requiring distributing keys with your application. We all know this is pretty unsafe since any hacker could yank them out. oAuth 2.0 does seem to solve a lot of the issues involving desktop applications, but is still being drafted. So maybe holding off basic auth depreciation until then might not be ideal, but I think it would help make porting to oAuth a bit easier. Just curious how soon can we expect 2.0 to be rolling out and if Twitter has considered at all extending basic auth's lifetime. Thanks, Josh -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] dev.twitter.com
I completely agree. Nice job! Sent from my Verizon Wireless BlackBerry -Original Message- From: Atul Kulkarni atulskulka...@gmail.com Date: Wed, 14 Apr 2010 16:38:32 To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] dev.twitter.com +1... this is nice. On Wed, Apr 14, 2010 at 4:27 PM, Dewald Pretorius dpr...@gmail.com wrote: Okay, this seriously rocks. Congrats to everyone who worked on making dev.twitter.com happen. -- To unsubscribe, reply using remove me as the subject. -- Regards, Atul Kulkarni
[twitter-dev] Re: dev.twitter.com
+1. Yup, had a great evening here watching the live stream. Next year I'll be there (I hope). On Apr 14, 10:38 pm, Atul Kulkarni atulskulka...@gmail.com wrote: +1... this is nice. On Wed, Apr 14, 2010 at 4:27 PM, Dewald Pretorius dpr...@gmail.com wrote: Okay, this seriously rocks. Congrats to everyone who worked on making dev.twitter.com happen. -- To unsubscribe, reply using remove me as the subject. -- Regards, Atul Kulkarni
[twitter-dev] Re: Favorites Error
This is happening for me as well. The problem can be easily recreated with the Twitter API explorer: http://twitapi.com/explore/favorites-create/ http://twitapi.com/explore/favorites-destroy/ -Brandon On Mar 30, 7:26 pm, Orian Marx (@orian) or...@orianmarx.com wrote: It seems thatfavorites/createandfavorites/destroy are no longer returning tweets with a properly updated favorited node. If I try to favorite a tweet, theresponsecomes back with favorited = false, but if I re-fetch the tweet immediately after it comes back as favorited = true. It was not working like this until very recently. Anybody else getting this? Thanks, @orian -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] dev.twitter.com
I just tweeted how much I like it. The console is a great touch. Well done, Taylor all at twitter. On 14 April 2010 23:05, Yogesh Mali yomali1...@gmail.com wrote: Awesome !! Nice work . On Wed, Apr 14, 2010 at 5:00 PM, Peter Denton petermden...@gmail.comwrote: Yeah, very nice work team. Thanks for doing this. On Wed, Apr 14, 2010 at 2:52 PM, Taylor Singletary taylorsinglet...@twitter.com wrote: Thanks for the positive feedback! We're working hard on making this always the most up to date resource as possible -- admittedly, there's still some work to do to get everything in agreement with the dynamic world of the wiki. Look for much more to come on this portal. It's going to keep getting more awesome! Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Wed, Apr 14, 2010 at 2:49 PM, Raffi Krikorian ra...@twitter.comwrote: cool - thanks - taylor has been spending a lot of time behind the scenes pushing this forward. he has always felt that having this portal was extremely important for developers, and he made it happen. On Wed, Apr 14, 2010 at 2:38 PM, Atul Kulkarni atulskulka...@gmail.com wrote: +1... this is nice. On Wed, Apr 14, 2010 at 4:27 PM, Dewald Pretorius dpr...@gmail.comwrote: Okay, this seriously rocks. Congrats to everyone who worked on making dev.twitter.com happen. -- To unsubscribe, reply using remove me as the subject. -- Regards, Atul Kulkarni -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: dev.twitter.com
What a cool stuff!!! Congrats, guys!!! On Wed, Apr 14, 2010 at 7:21 PM, Robby Grossman ro...@freerobby.com wrote: Why in peace? :P +1 on the positive sentiments. Looks great! --Robby On Apr 14, 3:16 pm, Josh Roesslein jroessl...@gmail.com wrote: Very nice! RIP apiwiki. Josh -- To unsubscribe, reply using remove me as the subject. -- Ernandes Jr. - ALL programs are poems. However, NOT all programmers are poets.
Re: [twitter-dev] Annotation details
I look forward to reading about this, sounds... intriguing. On 14 April 2010 22:50, Raffi Krikorian ra...@twitter.com wrote: we will be releasing data in due time! On Wed, Apr 14, 2010 at 2:05 PM, James Teters jtet...@gmail.com wrote: Just curious if there is any documentation on how annotations will be implemented? Any ideas on size limitations or restrictions for this meta data? -- To unsubscribe, reply using remove me as the subject. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] Changing access level of @anywhere applications
Hey, I have a quick question regarding @anywhere. Let's just say that we're very excited about it here where I work, and as soon as I learnt that it was alive I started working on integrating them to a few sites, starting with my own blog, just to try it out. Five minutes later, I had already integrated hovercards, follow buttons and a tweet box, and it was fantastic… except for the fact that I can't tweet or do anything with the hovercards. I assume it's because my application has a read-only access level, but I don't see a setting to change it or any information about this. What can I do to get write access to my apps? -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] User Stream's API usage
I'm in the chrip conference IP address range, but
http://chirpstream.twitter.com/2b/user.json usage isn't clear.
- the follow predicate in a POST doesn't work (should it?)
- track as a predicate gets accepted, but no data comes through (I get
a single '{friends:[]}', but that's it)
- am I supposed to be tracking userids or names or keywords?
is the resource simply not turned on until later at/on the hackathon's
network?
--
To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] User Stream's API usage
Email me your account name. You are in, but not getting data. Also, is
this account following anyone?
Typos by iPhone.
On Apr 14, 2010, at 4:11 PM, Jud jvale...@gmail.com wrote:
I'm in the chrip conference IP address range, but
http://chirpstream.twitter.com/2b/user.json usage isn't clear.
- the follow predicate in a POST doesn't work (should it?)
- track as a predicate gets accepted, but no data comes through (I get
a single '{friends:[]}', but that's it)
- am I supposed to be tracking userids or names or keywords?
is the resource simply not turned on until later at/on the hackathon's
network?
--
To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: User Stream's API usage
On Apr 14, 7:17 pm, John Kalucki j...@twitter.com wrote: Email me your account name. done You are in, but not getting data. Also, is this account following anyone? it is not -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Introduce yourself!
Hi. I'm Vidadi, coder from Russia. My NickName - SeoCoder. My first Twitter tools: #twittertime service - Find out how many days you are in a twitter - http://twitter.seocoder.org/ #UnFollower - standalone windows application writen in Delphi. UnFollow Who Not Follow U at http://www.seocoder.org/2010/03/25/twitter-pervaya-utilita-unfollower-udalyaem-tex-kto-nas-ne-followit/
[twitter-dev] Change label color of @anywhere Tweet-box
Is there a way to change the label color of @anywhere Tweet-box ? I tried adding style=color:#FF to the span id=placeholder/ span, but did not make any difference. -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Twitter
I'm creating something exciting... using Java, db4o and twitter. Would love to brainstorm with you. Mike
Re: [twitter-dev] Re: User Stream's API usage
If you aren't following anyone, and aren't tracking any terms, there's nothing to see, other than actions that occur on your account. So, if another account favorites this account's tweets, you'll see that, for example, or if another account follows your account, etc. Add some followings and reconnect to get something more interesting. -John Kalucki http://twitter.com/jkalucki Infrastructure, Twitter Inc. On Wed, Apr 14, 2010 at 4:33 PM, Jud jvale...@gmail.com wrote: On Apr 14, 7:17 pm, John Kalucki j...@twitter.com wrote: Email me your account name. done You are in, but not getting data. Also, is this account following anyone? it is not -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Changing access level of @anywhere applications
Hi Guillermo, You'll want to go to http://twitter.com/oauth and adjust your clients to have write access there for the time being. We'll re-enable the ability to toggle that status in edit mode on the dev portal soon. In the brave new world, all applications are read/write applications. Without fine-grained per-resource control, there's very little use in being black and white on read/write operations in totality. Personally, I think it's best to create an entirely new application record for @Anywhere. Separate concerns. Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod On Wed, Apr 14, 2010 at 3:46 PM, Guillermo Esteves g...@gesteves.com wrote: Hey, I have a quick question regarding @anywhere. Let's just say that we're very excited about it here where I work, and as soon as I learnt that it was alive I started working on integrating them to a few sites, starting with my own blog, just to try it out. Five minutes later, I had already integrated hovercards, follow buttons and a tweet box, and it was fantastic… except for the fact that I can't tweet or do anything with the hovercards. I assume it's because my application has a read-only access level, but I don't see a setting to change it or any information about this. What can I do to get write access to my apps? -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: Thoughts moving forward
I'm going to say that third-party developers should get together tonight at 9pm right at the end of Ignite Chirp. Look for me (with a 12 inch beard) and if you cant make it feel free to email me with anything you would like brought up. Abraham On Tue, Apr 13, 2010 at 15:48, Orian Marx (@orian) or...@orianmarx.comwrote: Anyone else want to join in on this? Ryan wants to chat about specifics in the 10:15 am session of the Hack Day, so I agree with Abraham that it makes sense to try and meet some time on Day 1 to collect some thoughts. I'm sure we'll have a lot of new info to digest as well. On Apr 12, 4:31 pm, Abraham Williams 4bra...@gmail.com wrote: I'm looking forward to Chirp and the dialogs that will happen. The Coop session on the second day looks to be the best time to have a heart to heart between third-party developers and the platform team. I think it would be good to have the third-party developers meet before then have a discussion about what we want and what our priorities are. I'm not sure when the best time would be. During the afternoon break or at 9pm on the first day seem like good times. I also think it would be respectful of Twitter employees to not attend this gathering so developers can be frank and honest. There will be many other opportunities. Abraham -- Abraham Williams | Developer for hire |http://abrah.am PoseurTech Labs | Projects |http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. -- To unsubscribe, reply using remove me as the subject. -- Abraham Williams | Developer for hire | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private.
[twitter-dev] Re: Annotation details
On Apr 14, 5:05 pm, James Teters jtet...@gmail.com wrote: Any ideas on size limitations or restrictions for this meta data? good question; I have the same one. simple math based on average tweet status byte size (of status structure coming through the streaming or REST interface) tells us that it wouldn't take much being jammed into the annotation's field to double that size. what status size increase is Twitter's infrastructure ready/willing to tolerate? it seems to me that a few things are NOT candidates for the annotations field(s): - void * (for you old schoolers on the list) - media who's original native format is binary (e.g. photos/videos) annotations will need limitations like: - overall size - if key/value pairs become the model... they'll need individual size limitations (for name and value) - max number of pairs - etc. the whole thing feels driven by the answer to the original size question. another question would be whether or not the tweet originator can remove annotations that others put on their tweet? I'd assume that I'd have control over my original tweet in that manner (e.g. notes functionality on Flickr) -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: Thoughts moving forward
Will be there. Telling the other devs around me. Zac Sent from my iPad On Apr 14, 2010, at 4:56 PM, Abraham Williams 4bra...@gmail.com wrote: I'm going to say that third-party developers should get together tonight at 9pm right at the end of Ignite Chirp. Look for me (with a 12 inch beard) and if you cant make it feel free to email me with anything you would like brought up. Abraham On Tue, Apr 13, 2010 at 15:48, Orian Marx (@orian) or...@orianmarx.com wrote: Anyone else want to join in on this? Ryan wants to chat about specifics in the 10:15 am session of the Hack Day, so I agree with Abraham that it makes sense to try and meet some time on Day 1 to collect some thoughts. I'm sure we'll have a lot of new info to digest as well. On Apr 12, 4:31 pm, Abraham Williams 4bra...@gmail.com wrote: I'm looking forward to Chirp and the dialogs that will happen. The Coop session on the second day looks to be the best time to have a heart to heart between third-party developers and the platform team. I think it would be good to have the third-party developers meet before then have a discussion about what we want and what our priorities are. I'm not sure when the best time would be. During the afternoon break or at 9pm on the first day seem like good times. I also think it would be respectful of Twitter employees to not attend this gathering so developers can be frank and honest. There will be many other opportunities. Abraham -- Abraham Williams | Developer for hire |http://abrah.am PoseurTech Labs | Projects |http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. -- To unsubscribe, reply using remove me as the subject. -- Abraham Williams | Developer for hire | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private.
[twitter-dev] Typos in @Anywhere Docs
Hi All, Playing around with @anywhere samples and noticed that there are varying references to: twttr.anywhere(onAnyWhereLoad); vs. twttr.anywhere(onAnywhereLoad); and... function onAnywhereLoad(twitter) vs. function onAnyWhereLoad(twitter) In some samples there is a mismatch of onAnyWhereLoad where W is either lowercase or uppercase. Unfortunately, this will cause the JS to halt because of OnAnyWhereLoad and OnAnywhereLoad are considered uniquely different. Spent 10 minutes wondering why the samples didn't work and noticed the typo. As I'm sure there will be a lot of people trying these samples, they may give up if they don't catch the typo. Best, Y.
[twitter-dev] Re: Typos in @Anywhere Docs
Forgot to include the doc url: http://dev.twitter.com/anywhere/begin On Apr 14, 10:07 pm, YCBM youcannotb...@gmail.com wrote: Hi All, Playing around with @anywhere samples and noticed that there are varying references to: twttr.anywhere(onAnyWhereLoad); vs. twttr.anywhere(onAnywhereLoad); and... function onAnywhereLoad(twitter) vs. function onAnyWhereLoad(twitter) In some samples there is a mismatch of onAnyWhereLoad where W is either lowercase or uppercase. Unfortunately, this will cause the JS to halt because of OnAnyWhereLoad and OnAnywhereLoad are considered uniquely different. Spent 10 minutes wondering why the samples didn't work and noticed the typo. As I'm sure there will be a lot of people trying these samples, they may give up if they don't catch the typo. Best, Y. -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Search API - 420 increase at 17:01 PDT
The Search API is returning 420 code this afternoon. Did something change at twitter? To my knowledge, nothing has changed at my location.
Re: [twitter-dev] Re: Annotation details
we're not sure on the sizes we are going to initially launch with, but i suspect we will launch with something small and ramp it up. i think the limit will also be the total sum of stuff, as opposed to number of keys, length of keys, etc. On Wed, Apr 14, 2010 at 5:43 PM, Jud jvale...@gmail.com wrote: On Apr 14, 5:05 pm, James Teters jtet...@gmail.com wrote: Any ideas on size limitations or restrictions for this meta data? good question; I have the same one. simple math based on average tweet status byte size (of status structure coming through the streaming or REST interface) tells us that it wouldn't take much being jammed into the annotation's field to double that size. what status size increase is Twitter's infrastructure ready/willing to tolerate? it seems to me that a few things are NOT candidates for the annotations field(s): - void * (for you old schoolers on the list) - media who's original native format is binary (e.g. photos/videos) annotations will need limitations like: - overall size - if key/value pairs become the model... they'll need individual size limitations (for name and value) - max number of pairs - etc. the whole thing feels driven by the answer to the original size question. another question would be whether or not the tweet originator can remove annotations that others put on their tweet? I'd assume that I'd have control over my original tweet in that manner (e.g. notes functionality on Flickr) -- To unsubscribe, reply using remove me as the subject. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] Re: Annotation details
Raffi, Is the planning for everyone's annotations to be available to everyone else, or will there be private namespaces accessible only to the source application? -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: Thoughts moving forward
Lets meet in The Perch area. Abraham On Thu, Apr 15, 2010 at 01:51, Zac Bowling zbowl...@gmail.com wrote: Will be there. Telling the other devs around me. Zac Sent from my iPad On Apr 14, 2010, at 4:56 PM, Abraham Williams 4bra...@gmail.com wrote: I'm going to say that third-party developers should get together tonight at 9pm right at the end of Ignite Chirp. Look for me (with a 12 inch beard) and if you cant make it feel free to email me with anything you would like brought up. Abraham On Tue, Apr 13, 2010 at 15:48, Orian Marx (@orian) or...@orianmarx.com or...@orianmarx.com wrote: Anyone else want to join in on this? Ryan wants to chat about specifics in the 10:15 am session of the Hack Day, so I agree with Abraham that it makes sense to try and meet some time on Day 1 to collect some thoughts. I'm sure we'll have a lot of new info to digest as well. On Apr 12, 4:31 pm, Abraham Williams 4bra...@gmail.com wrote: I'm looking forward to Chirp and the dialogs that will happen. The Coop session on the second day looks to be the best time to have a heart to heart between third-party developers and the platform team. I think it would be good to have the third-party developers meet before then have a discussion about what we want and what our priorities are. I'm not sure when the best time would be. During the afternoon break or at 9pm on the first day seem like good times. I also think it would be respectful of Twitter employees to not attend this gathering so developers can be frank and honest. There will be many other opportunities. Abraham -- Abraham Williams | Developer for hire | http://abrah.am http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. -- To unsubscribe, reply using remove me as the subject. -- Abraham Williams | Developer for hire | http://abrah.amhttp://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. -- Abraham Williams | Developer for hire | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private.
[twitter-dev] Re: High frequency of search API timeouts
Thanks for confirming. Glad I'm not alone! Are you using the source keyword in your queries? The more I try, the more I think that seems to be the problem since I can't recreate timeouts/long query times when I don't use it. But again, maybe not I'll work on not using it for now. But, thought I'd mention in case anybody from the twitter search team is out there. Nice app BTW, looks cool. rw On Apr 14, 8:56 am, Pykler hnass...@gmail.com wrote: I am a member of a team working on a new startup to classify twittersearchresults into various categories. Kinda cool, check itouthttp://twecan.com/. However, not all queries may work, and sometimes you would have to resubmit them as mentioned by Ryan. On Apr 12, 7:04 pm, Ryan W rwilli...@gmail.com wrote: Is anybody else seeing a high frequency ofsearchtimeouts? ... Seemed to be working fine until yesterday. YES! same thing. Here's the weird part though. First case: - execute complexsearchdirectly in browser and it timesoutlike my app gets on App Engine Second case: - run a simple, single word,searchin a browser - then run the complexsearchimmediately after and it works It's almost like it has to be primed? It also seems like the -source parameter is the problem, but that could just be anecdotal and clouded by my second case example above. To me it looked random, re-running the same query seems to work sometimes and then fail. We thought it was our caching strategy which we worked all night yesterday optimizing so that we don't hit twittersearchas much, yet we often get timedout. Wonder if someone is looking into this. -- Hatem Twecan Developerhttp://twecan.com- Twecan - Making sense of twittersearch -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Typos in @Anywhere Docs
Will fix up in the AM, thanks for the good eye. Taylor On Wednesday, April 14, 2010, YCBM youcannotb...@gmail.com wrote: Forgot to include the doc url: http://dev.twitter.com/anywhere/begin On Apr 14, 10:07 pm, YCBM youcannotb...@gmail.com wrote: Hi All, Playing around with @anywhere samples and noticed that there are varying references to: twttr.anywhere(onAnyWhereLoad); vs. twttr.anywhere(onAnywhereLoad); and... function onAnywhereLoad(twitter) vs. function onAnyWhereLoad(twitter) In some samples there is a mismatch of onAnyWhereLoad where W is either lowercase or uppercase. Unfortunately, this will cause the JS to halt because of OnAnyWhereLoad and OnAnywhereLoad are considered uniquely different. Spent 10 minutes wondering why the samples didn't work and noticed the typo. As I'm sure there will be a lot of people trying these samples, they may give up if they don't catch the typo. Best, Y. -- To unsubscribe, reply using remove me as the subject. -- Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod
[twitter-dev] Re: dev.twitter.com
First of all I'd like to add my thanks for this to everyone else's - a much nicer and more self-contained setup than we've had before, if not an entirely unexpected development. One issue I'd like to query (and apologies if this has come up before, I've not been watching the chirp streams) is whether dev.twitter.com is architected to be likely to survive major Twitter downtime? I'm sure you'll appreciate my point that uptime information is unlikely to be useful if we can't get it when the main Twitter site is undergoing technical issues itself. Whilst I can't claim to be any sort of network engineer or even to have a particularly good knowledge of the DNS system I wonder if you could possibly set dev.twitter.com up externally - that is, with another hosting provider and/or in a different location, in order to make sure it stays up (though obviously this might not be reasonably economical). On Apr 14, 10:27 pm, Dewald Pretorius dpr...@gmail.com wrote: Okay, this seriously rocks. Congrats to everyone who worked on making dev.twitter.com happen.
[twitter-dev] Re: Changing access level of @anywhere applications
Ah, that did the trick. Thank you so much. On Apr 14, 7:43 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Guillermo, You'll want to go tohttp://twitter.com/oauthand adjust your clients to have write access there for the time being. We'll re-enable the ability to toggle that status in edit mode on the dev portal soon. In the brave new world, all applications are read/write applications. Without fine-grained per-resource control, there's very little use in being black and white on read/write operations in totality. Personally, I think it's best to create an entirely new application record for @Anywhere. Separate concerns. Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod On Wed, Apr 14, 2010 at 3:46 PM, Guillermo Esteves g...@gesteves.com wrote: Hey, I have a quick question regarding @anywhere. Let's just say that we're very excited about it here where I work, and as soon as I learnt that it was alive I started working on integrating them to a few sites, starting with my own blog, just to try it out. Five minutes later, I had already integrated hovercards, follow buttons and a tweet box, and it was fantastic… except for the fact that I can't tweet or do anything with the hovercards. I assume it's because my application has a read-only access level, but I don't see a setting to change it or any information about this. What can I do to get write access to my apps? -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Infochimps Datasets available for Hack Day: drawn from 1.6B tweets, 40M+ users+reputation, ~0.5B reply links, more!
Hi flip, I'm hacking at chirp and am interested in a follows b, hashtags, and urls. What would be extra sweet would be timestamps on the follow relations, if you crawl the same person over time and we can see how that network evolves. Thanks for making the data available. Kovas Infoharmoni On Apr 14, 2010, at 1:51 PM, Philip (flip) Kromer f...@infochimps.org wrote: Hi all, I'm pleased to announce that Infochimps is making datasets from our massive scrape of the Twitter corpus available for Chirp Hack day devs. There's a big opportunity for apps that draw on the historical record and *structure* of twitter -- apps that require a global perspective and intense computation. The following are available to mash up against other datasets from infochimps.org or even just to bootstrap-seed the database for your Hack Day application. We also have a 30-machine cluster up to do further extractions, so if you have something really interesting you'd like to pull please let me know. Reputation Metrics from Reply and Follow graphs Uses algorithm similar to pagerank to derive reputation, one using the a_follows_b graph and one using the a_replies_b graphs Reply/retweet/mention graph Every observed Reply, retweet, or mention seen in a 1.6B-tweet sample (about 15% of historical record): a_[rel]_b, user_a_id, user_b_id, tweet_id Twitter Users by Background Color The number of users with each background color: color code, user count Twitter Users by Friends Count The number of users with a given number of friends: number of friends, user count Twitter Users by Followers Count The number of users with a given number of followers: number of followers, user count Twitter Users by Created At The number of users whose accounts were created in a given month/day/hour along with the earliest seen ID in that hour: timestamp to month/day/hour, user count Smileys Smiley faces with user, date, tweet_id Hashtags Hashtags with user, date, tweet_id TweetUrl URLs with user, date, tweet_id Twitter Users by Location The number of users in a location string (as provided by the user in their profile). location, user count Stock Tweets Tweets that include the stock symbol tag convention of $STOCKNAME or $$. The tweet is listed for each time a tag is used in the tweet. stock_tweet (resource name), symbol captured, tweet object (all things in a tweet) Stock Prices Daily stock prices for the NASDAQ, NYSE, AMEX exchanges 1970-now symbol, open, low, close, high, volume Parameters for what's available: raw object size number of objs a_follows_b 45.8 GB 1,587,838,568 a_mentions_b29.5 GB 493,682,309 a_retweets_b 1.6 GB36,022,061 twitter_user 3.1 GB43,261,388 tweets 376.0 GB 1,641,624,381 hashtag 7.1 GB 139,916,844 smiley 4.4 GB99,272,082 tweet_url 29.5 GB 433,278,116 If you'd like access to any of these, or have an idea that needs something /not/ here, please let me know (f...@infochimps.org). We're only opening access to Hack Day devs for now -- but please let us know your ideas so we can show twitter how much demand there is for aggregated access to data. best, flip @mrflip 512-659-6846 http://infochimps.org Find any dataset in the world
Re: [twitter-dev] User Stream's API usage
Hi,
Is there any description of how to use this? I don't understand how to
use track with this or what is generally available for hack day. Thanks!
On Apr 14, 2010, at 4:17 PM, John Kalucki j...@twitter.com wrote:
Email me your account name. You are in, but not getting data. Also,
is this account following anyone?
Typos by iPhone.
On Apr 14, 2010, at 4:11 PM, Jud jvale...@gmail.com wrote:
I'm in the chrip conference IP address range, but
http://chirpstream.twitter.com/2b/user.json usage isn't clear.
- the follow predicate in a POST doesn't work (should it?)
- track as a predicate gets accepted, but no data comes through (I
get
a single '{friends:[]}', but that's it)
- am I supposed to be tracking userids or names or keywords?
is the resource simply not turned on until later at/on the
hackathon's
network?
--
To unsubscribe, reply using remove me as the subject.
preserving consumer key secrecy (was: Re: [twitter-dev] Re: Basic Auth Deprecation)
On Wed, Apr 14, 2010 at 18:26, Raffi Krikorian ra...@twitter.com wrote: yes, it could be a problem - however, there are known solutions to obfuscating and keeping your consumer key secret. not perfect, but pretty good. maybe we can start a discussion around this? What's the known solution for an open-source Web-based application that I want to distribute to the world[1]? Make people get their own key is not an acceptable solution; neither is proxy all requests through your own web site and add the secret there. [1]: http://github.com/genehack/app-status-skein john.
[twitter-dev] @Anywhere fails if application access is revoked while the user is connected?
It seems that @Anywhere stops processing before reaching the initialization callback if a user revokes an application's access through Twitter.com while still signed into a connected site. During initialization, the call to verify_credentials fails with 401 Unauthorized (as expected), but the process does not then go on to indicate to the browser that the operation failed. Instead, the script apparently halts without going to the initialization callback and without unsetting the user's existing twttr_anywhere cookie. -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Hovercards with blogger.js?
I'm using the blogger.js script on my site to display my latest tweets, but the usernames are hrefs, and @anywhere doesn't seem to recognize them and add a hovercard for them (it works on the rest of my site)
[twitter-dev] Let's collaborate on Twitter's next killer app
I keep reading articles about the people at Twitter talking about its time to create the next killer app. When I hear things like that, my mind thinks big. I have a lot of great ideas and i'm sure you guys do too, so lets collaborate and come up with something like, absolutely mindblowing! We already have the tools to do it, but nobody's really thinking big enough. Email me at tstrickland...@gmail.com if your interested and we can set up a private google wave group or something and get brainstorming -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] change @Anywhere Connect with Twitter authorization callback url?
@Anywhere's Connect with Twitter flow appears to use the requesting site's root url as the callback url, rather than the callback url specified in the Application details. Can this be changed? -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Bug in Follow Button in Firefox
If the follow button is created in an iFrame on a foreign domain, the
button will not render in Firefox due to a XSS permissions error.
Consider this:
Page: abc.com/index.html
[
iframe: xyz.com/iframe.html
[
{Follow button}
]
]
Firefox will throw a Permission denied to call Location.href error
because the follow button code looks to window.top.location.href
instead of window.parent.location.href. An iframe shouldn't know about
the outermost frame, just its parent.
--
To unsubscribe, reply using remove me as the subject.
[twitter-dev] callback URL as 127.0.0.1
I am trying to setup a rails app in development mode on my local machine (http://127.0.0.1:3000) and I cannot get @Anywhere to let me register the app. It says that it is a Capcha error, but I really think it is a callback URL that isn't a normal domain name. Is it possible to setup an @Anywhere app for 127.0.0.1? -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Bug in Follow Button in Firefox
If the follow button is created in an iFrame on a foreign domain, the button will not render in Firefox due to a XSS permissions error. And that's undoubtedly on purpose. I don't think Twitter wants a potentially spoofable follow button. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- I may have invented CtrlAltDel, but Microsoft made it popular. -- D. Bradley -- To unsubscribe, reply using remove me as the subject.
Re: preserving consumer key secrecy (was: Re: [twitter-dev] Re: Basic Auth Deprecation)
yes, it could be a problem - however, there are known solutions to obfuscating and keeping your consumer key secret. __not perfect, but pretty good. __maybe we can start a discussion around this? What's the known solution for an open-source Web-based application that I want to distribute to the world[1]? Make people get their own key is not an acceptable solution; neither is proxy all requests through your own web site and add the secret there. I had the same question and was very gratified to find out that Raffi is in fact working on this very problem with the next draft of oAuth. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- mouse, n: A device for pointing at the xterm in which you want to type. -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Re: dev.twitter.com
The status page is available on a completely different domain. The rest of the dev information is not all that critical during downtime. http://status.watchmouse.com/7617 http://status.watchmouse.com/7617Abraham On Wed, Apr 14, 2010 at 23:26, 46Bit m...@46bit.com wrote: First of all I'd like to add my thanks for this to everyone else's - a much nicer and more self-contained setup than we've had before, if not an entirely unexpected development. One issue I'd like to query (and apologies if this has come up before, I've not been watching the chirp streams) is whether dev.twitter.com is architected to be likely to survive major Twitter downtime? I'm sure you'll appreciate my point that uptime information is unlikely to be useful if we can't get it when the main Twitter site is undergoing technical issues itself. Whilst I can't claim to be any sort of network engineer or even to have a particularly good knowledge of the DNS system I wonder if you could possibly set dev.twitter.com up externally - that is, with another hosting provider and/or in a different location, in order to make sure it stays up (though obviously this might not be reasonably economical). On Apr 14, 10:27 pm, Dewald Pretorius dpr...@gmail.com wrote: Okay, this seriously rocks. Congrats to everyone who worked on making dev.twitter.com happen. -- Abraham Williams | Developer for hire | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] User Stream's API usage
Some sample APIs...
curl -uyouruser:yourpass
http://chirpstream.twitter.com/2b/user.jsohttp://chirpstream.twitter.com/2b/user.json
n
Will give you a stream of your home timeline, social activity from your
friends, and direct messages.
curl -uyouruser:yourpass
http://chirpstream.twitter.com/2b/user.jsohttp://chirpstream.twitter.com/2b/user.json
n?track=#chirp
Will give you all of the above, plus any tweets matching #chirp
Does that clear it up? If not, I'm currently near The Coop.
---Mark
http://twitter.com/mccv
On Wed, Apr 14, 2010 at 6:37 PM, Kovas Boguts kovas.bog...@gmail.comwrote:
Hi,
Is there any description of how to use this? I don't understand how to use
track with this or what is generally available for hack day. Thanks!
On Apr 14, 2010, at 4:17 PM, John Kalucki j...@twitter.com wrote:
Email me your account name. You are in, but not getting data. Also, is
this account following anyone?
Typos by iPhone.
On Apr 14, 2010, at 4:11 PM, Jud jvale...@gmail.com wrote:
I'm in the chrip conference IP address range, but
http://chirpstream.twitter.com/2b/user.json usage isn't clear.
- the follow predicate in a POST doesn't work (should it?)
- track as a predicate gets accepted, but no data comes through (I get
a single '{friends:[]}', but that's it)
- am I supposed to be tracking userids or names or keywords?
is the resource simply not turned on until later at/on the hackathon's
network?
--
To unsubscribe, reply using remove me as the subject.
Re: preserving consumer key secrecy (was: Re: [twitter-dev] Re: Basic Auth Deprecation)
Why not just distribute a key with it? The worst that happens is someone uses it in their app and it gets disabled and some people get pissed off at you. I have yet to hear of this happening to a Twitter application. If someone abuses your key and Twitter does not handle the situation well I will personally call Sarver to bitch. :-P Abraham On Thu, Apr 15, 2010 at 02:09, John SJ Anderson geneh...@gmail.com wrote: On Wed, Apr 14, 2010 at 18:26, Raffi Krikorian ra...@twitter.com wrote: yes, it could be a problem - however, there are known solutions to obfuscating and keeping your consumer key secret. not perfect, but pretty good. maybe we can start a discussion around this? What's the known solution for an open-source Web-based application that I want to distribute to the world[1]? Make people get their own key is not an acceptable solution; neither is proxy all requests through your own web site and add the secret there. [1]: http://github.com/genehack/app-status-skein john. -- Abraham Williams | Developer for hire | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] App user counts missing from http://dev.twitter.com/apps
Hey Twitter team - http://dev.twitter.com/apps is missing user counts that twitter.com/ oauth was showing. Please put them back there, I would assume this is a temporary oversight. And add even more data! :) (like, users in last 7 days or so, in addition to total.) J -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] App user counts missing from http://dev.twitter.com/apps
Also suspended applications show up on http://dev.twitter.com/console http://dev.twitter.com/consoleAbraham On Thu, Apr 15, 2010 at 04:19, Jaanus jaa...@gmail.com wrote: Hey Twitter team - http://dev.twitter.com/apps is missing user counts that twitter.com/ oauth was showing. Please put them back there, I would assume this is a temporary oversight. And add even more data! :) (like, users in last 7 days or so, in addition to total.) J -- To unsubscribe, reply using remove me as the subject. -- Abraham Williams | Developer for hire | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private.
Re: [twitter-dev] User Stream's API usage
I should have encouraged folks to understand the Streaming API first. You
can read up on all the details here:
http://apiwiki.twitter.com/Streaming-API-Documentation
But, for a prototype, just dive right in.
-John
On Wed, Apr 14, 2010 at 9:15 PM, Mark McBride mmcbr...@twitter.com wrote:
Some sample APIs...
curl -uyouruser:yourpass
http://chirpstream.twitter.com/2b/user.jsohttp://chirpstream.twitter.com/2b/user.json
n
Will give you a stream of your home timeline, social activity from your
friends, and direct messages.
curl -uyouruser:yourpass
http://chirpstream.twitter.com/2b/user.jsohttp://chirpstream.twitter.com/2b/user.json
n?track=#chirp
Will give you all of the above, plus any tweets matching #chirp
Does that clear it up? If not, I'm currently near The Coop.
---Mark
http://twitter.com/mccv
On Wed, Apr 14, 2010 at 6:37 PM, Kovas Boguts kovas.bog...@gmail.comwrote:
Hi,
Is there any description of how to use this? I don't understand how to use
track with this or what is generally available for hack day. Thanks!
On Apr 14, 2010, at 4:17 PM, John Kalucki j...@twitter.com wrote:
Email me your account name. You are in, but not getting data. Also, is
this account following anyone?
Typos by iPhone.
On Apr 14, 2010, at 4:11 PM, Jud jvale...@gmail.com wrote:
I'm in the chrip conference IP address range, but
http://chirpstream.twitter.com/2b/user.json usage isn't clear.
- the follow predicate in a POST doesn't work (should it?)
- track as a predicate gets accepted, but no data comes through (I get
a single '{friends:[]}', but that's it)
- am I supposed to be tracking userids or names or keywords?
is the resource simply not turned on until later at/on the hackathon's
network?
--
To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] App user counts missing from http://dev.twitter.com/apps
It will remain missing for a bit for technical reasons. I'd love more comprehensive stats to be revealed there, but some implementations need to change (and be developed) first to make it possible. In the long term vision though. Those in the past who've had issues viewing their app details pages, might find viewing them on the dev portal now possible though.. ;) It's obviously a good number to know, but it's also a number you should be able to derive through good monitoring in your own application... Taylor On Wednesday, April 14, 2010, Jaanus jaa...@gmail.com wrote: Hey Twitter team - http://dev.twitter.com/apps is missing user counts that twitter.com/ oauth was showing. Please put them back there, I would assume this is a temporary oversight. And add even more data! :) (like, users in last 7 days or so, in addition to total.) J -- To unsubscribe, reply using remove me as the subject. -- Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod
Re: [twitter-dev] App user counts missing from http://dev.twitter.com/apps
Good find, Abraham. I'll get that tracked and fixed. Taylor On Wednesday, April 14, 2010, Abraham Williams 4bra...@gmail.com wrote: Also suspended applications show up on http://dev.twitter.com/console http://dev.twitter.com/consoleAbraham On Thu, Apr 15, 2010 at 04:19, Jaanus jaa...@gmail.com wrote: Hey Twitter team - http://dev.twitter.com/apps is missing user counts that twitter.com/ oauth was showing. Please put them back there, I would assume this is a temporary oversight. And add even more data! :) (like, users in last 7 days or so, in addition to total.) J -- To unsubscribe, reply using remove me as the subject. -- Abraham Williams | Developer for hire | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. -- Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod
Re: [twitter-dev] dev.twitter.com
That URL can also be found as http://apistatus.twitter.com now. Enjoy. It will work as long as Watchmouse is up. There's more info there than I even know what to do with. Y'all can thank Watchmouse and especially @mccv for the careful curation of that dashboard. There's more we can do in this area as well. Taylor On Wednesday, April 14, 2010, Abraham Williams 4bra...@gmail.com wrote: The status page is available on a completely different domain. The rest of the dev information is not all that critical during downtime. http://status.watchmouse.com/7617 http://status.watchmouse.com/7617Abraham On Wed, Apr 14, 2010 at 23:26, 46Bit m...@46bit.com wrote: First of all I'd like to add my thanks for this to everyone else's - a much nicer and more self-contained setup than we've had before, if not an entirely unexpected development. One issue I'd like to query (and apologies if this has come up before, I've not been watching the chirp streams) is whether dev.twitter.com is architected to be likely to survive major Twitter downtime? I'm sure you'll appreciate my point that uptime information is unlikely to be useful if we can't get it when the main Twitter site is undergoing technical issues itself. Whilst I can't claim to be any sort of network engineer or even to have a particularly good knowledge of the DNS system I wonder if you could possibly set dev.twitter.com up externally - that is, with another hosting provider and/or in a different location, in order to make sure it stays up (though obviously this might not be reasonably economical). On Apr 14, 10:27 pm, Dewald Pretorius dpr...@gmail.com wrote: Okay, this seriously rocks. Congrats to everyone who worked on making dev.twitter.com happen. -- Abraham Williams | Developer for hire | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. -- Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] App user counts missing from http://dev.twitter.com/apps
You should also consider SSL for /apps and /console. Abraham On Thu, Apr 15, 2010 at 04:27, Taylor Singletary taylorsinglet...@twitter.com wrote: Good find, Abraham. I'll get that tracked and fixed. Taylor On Wednesday, April 14, 2010, Abraham Williams 4bra...@gmail.com wrote: Also suspended applications show up on http://dev.twitter.com/console http://dev.twitter.com/consoleAbraham On Thu, Apr 15, 2010 at 04:19, Jaanus jaa...@gmail.com wrote: Hey Twitter team - http://dev.twitter.com/apps is missing user counts that twitter.com/ oauth was showing. Please put them back there, I would assume this is a temporary oversight. And add even more data! :) (like, users in last 7 days or so, in addition to total.) J -- To unsubscribe, reply using remove me as the subject. -- Abraham Williams | Developer for hire | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. -- Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod -- Abraham Williams | Developer for hire | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private.
[twitter-dev] Re: dev.twitter.com
This is great. I love the twurl interface at http://dev.twitter.com/console Just a thought/suggestion, a link to the documentation when a method is chosen from the drop down list. Its not critical, i can look it up; it would just be a nice extra to save me a few extra clicks. --Naveen Ayyagari @knight9 @SocialScope -- To unsubscribe, reply using remove me as the subject.
Re: [twitter-dev] Hovercards with blogger.js?
Anywhere ignores already linked screen_names. Abraham On Thu, Apr 15, 2010 at 02:25, Jonah Grant grantjo...@gmail.com wrote: I'm using the blogger.js script on my site to display my latest tweets, but the usernames are hrefs, and @anywhere doesn't seem to recognize them and add a hovercard for them (it works on the rest of my site) -- Abraham Williams | Developer for hire | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] account/verify_credentials rate limited
Now that account/verify_credentials is rate limited there is no way to verify tokens are valid if a user has exceded there GET limit. Abraham -- Abraham Williams | Developer for hire | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private.
Re: [twitter-dev] dev.twitter.com
Good suggestion, thanks. Most documentation, conversely, link to Twurl from each example representation. These will become more comprehensive over time. It will be better. Taylor On Wednesday, April 14, 2010, Naveen Ayyagari nav...@getsocialscope.com wrote: This is great. I love the twurl interface at http://dev.twitter.com/console Just a thought/suggestion, a link to the documentation when a method is chosen from the drop down list. Its not critical, i can look it up; it would just be a nice extra to save me a few extra clicks. --Naveen Ayyagari @knight9 @SocialScope -- To unsubscribe, reply using remove me as the subject. -- Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod
Re: [twitter-dev] callback URL as 127.0.0.1
The error handling on those screens will get better. Not possible at this time, but we're evaluating making it possible, while in a development mode of sorts. Taylor On Wednesday, April 14, 2010, tux_advocate_hpu tuxcod...@gmail.com wrote: I am trying to setup a rails app in development mode on my local machine (http://127.0.0.1:3000) and I cannot get @Anywhere to let me register the app. It says that it is a Capcha error, but I really think it is a callback URL that isn't a normal domain name. Is it possible to setup an @Anywhere app for 127.0.0.1? -- To unsubscribe, reply using remove me as the subject. -- Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod
Re: [twitter-dev] change @Anywhere Connect with Twitter authorization callback url?
For now, consider everything @Anywhere does with callback urls a transparent implementation detail. The callback you supply really is to establish the domain and subdomain of your application. @Anywhere works by using the current page for it's callback operations. Taylor On Wednesday, April 14, 2010, jtcalhoun jtcalh...@gmail.com wrote: @Anywhere's Connect with Twitter flow appears to use the requesting site's root url as the callback url, rather than the callback url specified in the Application details. Can this be changed? -- To unsubscribe, reply using remove me as the subject. -- Taylor Singletary Developer Advocate, Twitter http://twitter.com/episod
Re: [twitter-dev] Re: High frequency of search API timeouts
There is a known issue with source and the search api that will be fixed on the search deploy next week. Jonathan On Wed, Apr 14, 2010 at 8:24 PM, Ryan W rwilli...@gmail.com wrote: Thanks for confirming. Glad I'm not alone! Are you using the source keyword in your queries? The more I try, the more I think that seems to be the problem since I can't recreate timeouts/long query times when I don't use it. But again, maybe not I'll work on not using it for now. But, thought I'd mention in case anybody from the twitter search team is out there. Nice app BTW, looks cool. rw On Apr 14, 8:56 am, Pykler hnass...@gmail.com wrote: I am a member of a team working on a new startup to classify twittersearchresults into various categories. Kinda cool, check itouthttp:// twecan.com/. However, not all queries may work, and sometimes you would have to resubmit them as mentioned by Ryan. On Apr 12, 7:04 pm, Ryan W rwilli...@gmail.com wrote: Is anybody else seeing a high frequency ofsearchtimeouts? ... Seemed to be working fine until yesterday. YES! same thing. Here's the weird part though. First case: - execute complexsearchdirectly in browser and it timesoutlike my app gets on App Engine Second case: - run a simple, single word,searchin a browser - then run the complexsearchimmediately after and it works It's almost like it has to be primed? It also seems like the -source parameter is the problem, but that could just be anecdotal and clouded by my second case example above. To me it looked random, re-running the same query seems to work sometimes and then fail. We thought it was our caching strategy which we worked all night yesterday optimizing so that we don't hit twittersearchas much, yet we often get timedout. Wonder if someone is looking into this. -- Hatem Twecan Developerhttp://twecan.com- Twecan - Making sense of twittersearch -- To unsubscribe, reply using remove me as the subject.
