Re: New API methods to retrieve social graph without pagination
This is really useful, however would be even more useful if you offered an unrate limited service to return the username for each userid. Problems I foresee. 1 user uses your web based app and the user has 10k followers and 10k friends and thats your limit used up for the hour. Even with caching using this is pointless for apps with large numbers of users. solutions that would work for me. return the user name as well as userid(yes I know this can change but most people will want to get it, make it optional) or let us use the search api to return user data using a userid like the username. On Feb 5, 3:07 am, James Deville james.devi...@gmail.com wrote: Any chance of a easy way to map this to usernames? We want the friends list for Witty (and I imagine others), but we don't need full profiles, just this + username. This won't help us otherwise since we'll need to map the entire list to usernames, which will require too many requests. JD On Wed, Feb 4, 2009 at 4:31 PM, Alex Payne a...@twitter.com wrote: The response should be ordered with most recent followed/followers first in the list. Another developer noted duplicates; we'll look into that. Matt K. wrote: Alex - This is a great addition to the API - will make things much easier. Quick question (and I apologize if this is already documented): do the followers / friends always come in descending order of when they friendship/follow was created? In other words will the most recent follow/friend always be first? I know the original followers call was ordered in the order in which the follower joined twitter. Hoping this isn't set up the same way - it would be nice to basically stop iterating over the list once a repeat friend/follower is found. Thanks for the clarification, Matt On Feb 3, 5:01 pm, Alex Paynea...@twitter.com wrote: Happy to announce two new API methods today, delivered in response to developer demand for an easier way to keep tabs on users' social graphs. The methods, /friends/ids and /followers/ids, return the entire list of numeric user IDs for a user's set of followed and following users, respectively. Responses to these methods are cached until the user's social graph changes. The responses come direct from our denormalized list data stores, and should be reasonably fast even for users with a large number of followers/follows. These new methods are most useful for services that are maintaining a cache of user details. If you see a user ID that you don't have cached, you'll have to call /users/show to retrieve that user's details. But for services with large user bases, or those that simply want to diff a user's social graph over time, we hope these methods will come in handy. You can find the documentation athttp:// apiwiki.twitter.com/REST-API-Documentation#SocialGraphMethods. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: New API methods to retrieve social graph without pagination
On 2/5/09, Ninjamonk dar...@stuartmedia.co.uk wrote: This is really useful, however would be even more useful if you offered an unrate limited service to return the username for each userid. On Feb 5, 3:07 am, James Deville james.devi...@gmail.com wrote: Any chance of a easy way to map this to usernames? We want the friends list for Witty (and I imagine others), but we don't need full profiles, just this + username. This won't help us otherwise since we'll need to map the entire list to usernames, which will require too many requests. I agree that having the username would be useful. If it's not a bunch of extra strain to include it, that would be splendid. If we have the username, we can build URLs to Twitter profile pages and/or display something meaningful (a name) to a user. thanks, -damon -- http://twitter.com/damon
Re: How API will works after OAuth?
Have you guys considered maybe tweaking the basic auth system to something like what friendfeed has. Each user could be given a third party system generated key to use instead of a password and then basic auth could still be used and not tired to the system password. If the user felt their account had been compromised by an app they could just generate a new code and also this would protect the users account from hijacking. I know you don't want to have 2 different systems for auth but this could be used for legacy apps and for use cases like funkatron mentioned earlier in the thread. Cheers On Feb 5, 4:59 am, Cameron Kaiser spec...@floodgap.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. I appreciate the consideration. :) -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com -- Another visitor. Stay awhile. Stay forever! -- Professor Elvin Atombender --
Re: Retrieving multiple arbitrary messages
Did that. Thanks.
Re: Retrieving multiple arbitrary messages
For posterity's sake, this issue is being tracked here http://code.google.com/p/twitter-api/issues/detail?id=267 @dougw On Feb 5, 3:38 am, skieter prau...@gmail.com wrote: Did that. Thanks.
Re: New API methods to retrieve social graph without pagination
Thanks Alex, I too, would like to see this return userids AND usernames. -Joel On Feb 3, 5:01 pm, Alex Payne a...@twitter.com wrote: Happy to announce two new API methods today, delivered in response to developer demand for an easier way to keep tabs on users' social graphs. The methods, /friends/ids and /followers/ids, return the entire list of numeric user IDs for a user's set of followed and following users, respectively. Responses to these methods are cached until the user's social graph changes. The responses come direct from our denormalized list data stores, and should be reasonably fast even for users with a large number of followers/follows. These new methods are most useful for services that are maintaining a cache of user details. If you see a user ID that you don't have cached, you'll have to call /users/show to retrieve that user's details. But for services with large user bases, or those that simply want to diff a user's social graph over time, we hope these methods will come in handy. You can find the documentation athttp://apiwiki.twitter.com/REST-API-Documentation#SocialGraphMethods. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: How API will works after OAuth?
I was just thinking this, and then I read your post. It would be good to see a trusted apps section somewhere on your site, and those application could use Basic Auth. If they don't want to go through the process of being a trusted app, then they can use OAuth. Just something to think about. Could earn twitter some $$$ too. -Joel On Feb 4, 8:57 pm, Alex Payne a...@twitter.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. funkatron wrote: Agreed. I do believe that the use of HTTP Basic Auth was key to the quick growth of the 3rd-party app community of Twitter, as the auth scheme is so well-understood and supported. This may or may not be as important at this point business-wise, as I suspect the Twitter userbase is large enough to overcome a fair bit of lazy user intertia. I wonder if we will see a lot less interesting API hacking (the good kind), though, and I think that would be a shame. While OAuth makes a ton of sense for website-based apps, it's kind of another kettle of fish for locally-hosted apps (desktop and mobile). Moving to OAuth-only is problematic for us for these reasons: 1. it complicates (and confuses) the process for users: instead of entering a username and password -- a well-understood, common process -- now the app has to push the user to a web site which hopefully explains what's going on decently. This works okay for web dorks like us, but I guarantee your avg user is going to find this confusing. Maybe not as confusing as OpenID, though. 2. updating locally-hosted apps to use a new authentication system is an issue of getting thousands (or higher orders) of users to upgrade. 6 months may not be enough, even for currently active applications. Stuff in development *cough*like mine*cough* now could find themselves having to toss out a ton of code they're knee-deep in right now. Yucky. My preference would be to *not* see HTTP Basic Auth go away in the foreseeable future. If that's not reasonable or possible, the 6-month window (even given that the countdown may not start for a few months) is pretty tight for comfort, and extending it would be much preferred. Note: One might wonder why I only mention these issues in the context of local apps rather than web apps. I think the expectations and user behavior tendencies are fairly different in the desktop and mobile app space, and there are a number of ways malware is detected and contained in this area. The web app space is a lot more open and easy to exploit, and likely will be unless the whole paradigm changes. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 4, 10:03 pm, Cameron Kaiserspec...@floodgap.com wrote: I'm still (softly) repeating the hope that this will be extended, even if the Basic Auth API remains deprecated and static. An OAuth workflow is constrained for desktop apps, and for apps that aren't or can't use a web browser (in my case, text-mode twitter clients; other cases include all those little curl scripts posting monitoring information, task status, etc.), OAuth won't work at all. I fully support OAuth, but where appropriate. I think Ed Finkler said it best when he said the breadth of Twitter applications currently extant wouldn't exist were it not for a low barrier to entry. OAuth makes sense in many places, but it doesn't make sense everywhere, and I hope alternate methods of authentication remain possible even if they are intentionally limited to steer preferred traffic to an OAuth workflow. Otherwise I suspect the ecosystem outside the browser will be greatly reduced. -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com*ckai...@floodgap.com -- Critics are the unpaid guardians of my soul. -- E. Stanley Jones --- -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: How API will works after OAuth?
2009/2/5 jstrellner jstrell...@urltrends.com: I was just thinking this, and then I read your post. It would be good to see a trusted apps section somewhere on your site, and those application could use Basic Auth. If they don't want to go through the process of being a trusted app, then they can use OAuth. Just something to think about. Could earn twitter some $$$ too. Could also land them in a world of pain. I wouldn't want Twitter to endorse any product that wasn't theirs, and I doubt they would want to either. Too risky. -Stuart On Feb 4, 8:57 pm, Alex Payne a...@twitter.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. funkatron wrote: Agreed. I do believe that the use of HTTP Basic Auth was key to the quick growth of the 3rd-party app community of Twitter, as the auth scheme is so well-understood and supported. This may or may not be as important at this point business-wise, as I suspect the Twitter userbase is large enough to overcome a fair bit of lazy user intertia. I wonder if we will see a lot less interesting API hacking (the good kind), though, and I think that would be a shame. While OAuth makes a ton of sense for website-based apps, it's kind of another kettle of fish for locally-hosted apps (desktop and mobile). Moving to OAuth-only is problematic for us for these reasons: 1. it complicates (and confuses) the process for users: instead of entering a username and password -- a well-understood, common process -- now the app has to push the user to a web site which hopefully explains what's going on decently. This works okay for web dorks like us, but I guarantee your avg user is going to find this confusing. Maybe not as confusing as OpenID, though. 2. updating locally-hosted apps to use a new authentication system is an issue of getting thousands (or higher orders) of users to upgrade. 6 months may not be enough, even for currently active applications. Stuff in development *cough*like mine*cough* now could find themselves having to toss out a ton of code they're knee-deep in right now. Yucky. My preference would be to *not* see HTTP Basic Auth go away in the foreseeable future. If that's not reasonable or possible, the 6-month window (even given that the countdown may not start for a few months) is pretty tight for comfort, and extending it would be much preferred. Note: One might wonder why I only mention these issues in the context of local apps rather than web apps. I think the expectations and user behavior tendencies are fairly different in the desktop and mobile app space, and there are a number of ways malware is detected and contained in this area. The web app space is a lot more open and easy to exploit, and likely will be unless the whole paradigm changes. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 4, 10:03 pm, Cameron Kaiserspec...@floodgap.com wrote: I'm still (softly) repeating the hope that this will be extended, even if the Basic Auth API remains deprecated and static. An OAuth workflow is constrained for desktop apps, and for apps that aren't or can't use a web browser (in my case, text-mode twitter clients; other cases include all those little curl scripts posting monitoring information, task status, etc.), OAuth won't work at all. I fully support OAuth, but where appropriate. I think Ed Finkler said it best when he said the breadth of Twitter applications currently extant wouldn't exist were it not for a low barrier to entry. OAuth makes sense in many places, but it doesn't make sense everywhere, and I hope alternate methods of authentication remain possible even if they are intentionally limited to steer preferred traffic to an OAuth workflow. Otherwise I suspect the ecosystem outside the browser will be greatly reduced. -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com*ckai...@floodgap.com -- Critics are the unpaid guardians of my soul. -- E. Stanley Jones --- -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- http://stut.net/
Re: New API methods to retrieve social graph without pagination
For all those wanting id AND username attributes to be returned with these new methods, be sure to head over to http://code.google.com/p/twitter-api/issues/detail?id=265 and vote (click the star) to signal your support. @dougw On Feb 5, 11:40 am, jstrellner jstrell...@urltrends.com wrote: Thanks Alex, I too, would like to see this return userids AND usernames. -Joel On Feb 3, 5:01 pm, Alex Payne a...@twitter.com wrote: Happy to announce two new API methods today, delivered in response to developer demand for an easier way to keep tabs on users' social graphs. The methods, /friends/ids and /followers/ids, return the entire list of numeric user IDs for a user's set of followed and following users, respectively. Responses to these methods are cached until the user's social graph changes. The responses come direct from our denormalized list data stores, and should be reasonably fast even for users with a large number of followers/follows. These new methods are most useful for services that are maintaining a cache of user details. If you see a user ID that you don't have cached, you'll have to call /users/show to retrieve that user's details. But for services with large user bases, or those that simply want to diff a user's social graph over time, we hope these methods will come in handy. You can find the documentation athttp://apiwiki.twitter.com/REST-API-Documentation#SocialGraphMethods. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: How API will works after OAuth?
Guys,
We all know that base-auth is a gold for our app and when we think about
another way like OAuth we get mad
BUT
If the Toke had infinit life time (probabily will do), so the big poblem
transform in a little problem with 3 steps:
1-Your Webapp redirect the user to Twitter Web Site (Authentication)
2- User put username and password
3- Twitter redirect again the user for your Webapp authenticated.
For non-web app it a little different but easy any way...
It's not a big deal...
The most important point is the life time of token... bring OAuth and let's
made this happen !!!
On Thu, Feb 5, 2009 at 2:48 PM, Stuart stut...@gmail.com wrote:
2009/2/5 jstrellner jstrell...@urltrends.com:
I was just thinking this, and then I read your post. It would be good
to see a trusted apps section somewhere on your site, and those
application could use Basic Auth. If they don't want to go through
the process of being a trusted app, then they can use OAuth.
Just something to think about. Could earn twitter some $$$ too.
Could also land them in a world of pain. I wouldn't want Twitter to
endorse any product that wasn't theirs, and I doubt they would want to
either. Too risky.
-Stuart
On Feb 4, 8:57 pm, Alex Payne a...@twitter.com wrote:
Thanks for the feedback, guys. We'll consider extending Basic Auth's
life, or maybe granting a stay of execution to known-good apps. At the
very least, we'll try not to pull the rug out from under anyone.
funkatron wrote:
Agreed. I do believe that the use of HTTP Basic Auth was key to the
quick growth of the 3rd-party app community of Twitter, as the auth
scheme is so well-understood and supported. This may or may not be as
important at this point business-wise, as I suspect the Twitter
userbase is large enough to overcome a fair bit of lazy user intertia.
I wonder if we will see a lot less interesting API hacking (the good
kind), though, and I think that would be a shame.
While OAuth makes a ton of sense for website-based apps, it's kind of
another kettle of fish for locally-hosted apps (desktop and mobile).
Moving to OAuth-only is problematic for us for these reasons:
1. it complicates (and confuses) the process for users: instead of
entering a username and password -- a well-understood, common process
-- now the app has to push the user to a web site which hopefully
explains what's going on decently. This works okay for web dorks like
us, but I guarantee your avg user is going to find this confusing.
Maybe not as confusing as OpenID, though.
2. updating locally-hosted apps to use a new authentication system is
an issue of getting thousands (or higher orders) of users to upgrade.
6 months may not be enough, even for currently active applications.
Stuff in development *cough*like mine*cough* now could find themselves
having to toss out a ton of code they're knee-deep in right now.
Yucky.
My preference would be to *not* see HTTP Basic Auth go away in the
foreseeable future. If that's not reasonable or possible, the 6-month
window (even given that the countdown may not start for a few
months) is pretty tight for comfort, and extending it would be much
preferred.
Note: One might wonder why I only mention these issues in the context
of local apps rather than web apps. I think the expectations and user
behavior tendencies are fairly different in the desktop and mobile app
space, and there are a number of ways malware is detected and
contained in this area. The web app space is a lot more open and easy
to exploit, and likely will be unless the whole paradigm changes.
--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron
On Feb 4, 10:03 pm, Cameron Kaiserspec...@floodgap.com wrote:
I'm still (softly) repeating the hope that this will be extended,
even if
the Basic Auth API remains deprecated and static. An OAuth workflow
is
constrained for desktop apps, and for apps that aren't or can't use a
web
browser (in my case, text-mode twitter clients; other cases include
all those
little curl scripts posting monitoring information, task status,
etc.), OAuth
won't work at all.
I fully support OAuth, but where appropriate. I think Ed Finkler said
it
best when he said the breadth of Twitter applications currently
extant
wouldn't exist were it not for a low barrier to entry. OAuth makes
sense
in many places, but it doesn't make sense everywhere, and I hope
alternate
methods of authentication remain possible even if they are
intentionally
limited to steer preferred traffic to an OAuth workflow. Otherwise I
suspect
the ecosystem outside the browser will be greatly reduced.
--
personal:
http://www.cameronkaiser.com/--
Cameron Kaiser * Floodgap Systems *www.floodgap.com*
ckai...@floodgap.com
--
Re: How API will works after OAuth?
I was just thinking this, and then I read your post. It would be good to see a trusted apps section somewhere on your site, and those application could use Basic Auth. If they don't want to go through the process of being a trusted app, then they can use OAuth. Something like that would almost certainly need *some* kind of app key, but we can speculate on that when the time comes. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- You only live twice. ---
Re: How API will works after OAuth?
We all know that base-auth is a gold for our app and when we think about another way like OAuth we get mad BUT If the Toke had infinit life time (probabily will do), so the big poblem transform in a little problem with 3 steps: 1-Your Webapp redirect the user to Twitter Web Site (Authentication) 2- User put username and password 3- Twitter redirect again the user for your Webapp authenticated. Right, for webapps this is a bit of pain but it's still workable into a workflow since you're still in a browser. The point Ed and I were making is that for *local* or *desktop* apps, you might not be anywhere near a browser or browser-like-thing at all, so OAuth would either be a serious constraint or actually not possible. But you're quite right for third-party webapps. It hurts a bit, but it is workable, and the benefits outweigh the disadvantages. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- FOOLS! I WILL DESTROY YOU ALL! ASK ME HOW! -- Girl Genius 8/29/07
Re: How API will works after OAuth?
I'll keep that in mind as an option, but it's not particularly user-friendly. Basic Auth lets users use the password they know; OAuth keeps users from having to worry about passwords at all. This setup requires users to keep track of some other strange value. Developers understand it, so it's a fine setup for a site like GitHub, but it doesn't seem like a good approach for a more general and potentially non-technical user base. Lucas Araujo wrote: I agree, remote key is a very cool feature. Lucas Araujo FriendFeed-as3 - An Actionscript 3 version of Friendfeed API http://code.google.com/p/friendfeed-as3/ On Thu, Feb 5, 2009 at 09:37, Ninjamonk dar...@stuartmedia.co.uk mailto:dar...@stuartmedia.co.uk wrote: Have you guys considered maybe tweaking the basic auth system to something like what friendfeed has. Each user could be given a third party system generated key to use instead of a password and then basic auth could still be used and not tired to the system password. If the user felt their account had been compromised by an app they could just generate a new code and also this would protect the users account from hijacking. I know you don't want to have 2 different systems for auth but this could be used for legacy apps and for use cases like funkatron mentioned earlier in the thread. Cheers On Feb 5, 4:59 am, Cameron Kaiser spec...@floodgap.com mailto:spec...@floodgap.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. I appreciate the consideration. :) -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com http://www.floodgap.com* ckai...@floodgap.com mailto:ckai...@floodgap.com -- Another visitor. Stay awhile. Stay forever! -- Professor Elvin Atombender -- -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: How API will works after OAuth?
So, what happen if this third party expose to others app this generated key? They will acess your account too? If this key can be just used for one app (maybe lock for one IP) the user will need generated always a new key for one app? (Go to twitter page, log in, acess New Keys, generate a new key, and give to the app) On Thu, Feb 5, 2009 at 10:37 AM, Ninjamonk dar...@stuartmedia.co.uk wrote: Have you guys considered maybe tweaking the basic auth system to something like what friendfeed has. Each user could be given a third party system generated key to use instead of a password and then basic auth could still be used and not tired to the system password. If the user felt their account had been compromised by an app they could just generate a new code and also this would protect the users account from hijacking. I know you don't want to have 2 different systems for auth but this could be used for legacy apps and for use cases like funkatron mentioned earlier in the thread. Cheers -- -- Analista Desenvolvedor www.espacodj.com
Re: How API will works after OAuth?
Hi Matt, Thx for answer... OAuth isn't hard ;) A couple of days i have learned some about it and put this on my TestApp to see how works. I'm glad to see that You guys worrie about the final user. Let's bring it on... We had just to generate our api_key and secret, and sort all parameters of the method (including api_key and secret) to creat a signature... (basically of course) So... don't worrie with us (developers) On Thu, Feb 5, 2009 at 4:33 PM, Matt Sanford m...@twitter.com wrote: Hi Gustavo et al, This is the problem with re-use systems like both Basic Auth and the FriendFeed token system. Every application uses the same token so you turn them all off at once (like a password change). Even if we give out one key per application (like OAuth) your requests can be intercepted and the credentials re-used (unless SSL is required). This sort of re-use is not a problem in OAuth where requests are signed using a secret and include a time stamp and a random value (nonce). Since the nonce can't be re-used this even guards against replay attacks.I know OAuth is hard. I've implemented the server side, a Scala test library and a sample Rails app (blog post coming soon). Having said that, all of the times I've wondered why it has to be so difficult I've come up with an attack scenario that means that part can't be dropped. I want to try and keep up Basic Auth as long as it's needed, but on the other hand I don't want to be like Microsoft who keep around LANMAN as an attack vector for years on end. It's a tough balance between encouraging developers and protecting our users. Thanks; — Matt On Feb 5, 2009, at 10:13 AM, Gustavo Melo wrote: So, what happen if this third party expose to others app this generated key? They will acess your account too? If this key can be just used for one app (maybe lock for one IP) the user will need generated always a new key for one app? (Go to twitter page, log in, acess New Keys, generate a new key, and give to the app) On Thu, Feb 5, 2009 at 10:37 AM, Ninjamonk dar...@stuartmedia.co.ukwrote: Have you guys considered maybe tweaking the basic auth system to something like what friendfeed has. Each user could be given a third party system generated key to use instead of a password and then basic auth could still be used and not tired to the system password. If the user felt their account had been compromised by an app they could just generate a new code and also this would protect the users account from hijacking. I know you don't want to have 2 different systems for auth but this could be used for legacy apps and for use cases like funkatron mentioned earlier in the thread. Cheers -- -- Analista Desenvolvedor www.espacodj.com -- -- Analista Desenvolvedor www.espacodj.com
Re: How API will works after OAuth?
I am not suggesting that they endorse the application, but that they have a process that is available to desktop apps that lets them keep using Basic Auth. Once twitter has OK'd the app, then that app can display a badge of some sort letting its users know that they have an agreement directly with Twitter that makes it OK to enter your username/password. I would think that part of the process of approval would include a contract of some sort that specifies exactly what the app can do with that data. @Cameron, I would also agree that an app key would be required in this case, specifically so that Twitter could revoke Basic Auth logins from that app if they were found to be violating the terms of the contract. If that key was disabled, no one would be able to use Twitter from that app, and thus, the app maker would make sure that they were in compliance. -Joel On Feb 5, 8:48 am, Stuart stut...@gmail.com wrote: 2009/2/5 jstrellner jstrell...@urltrends.com: I was just thinking this, and then I read your post. It would be good to see a trusted apps section somewhere on your site, and those application could use Basic Auth. If they don't want to go through the process of being a trusted app, then they can use OAuth. Just something to think about. Could earn twitter some $$$ too. Could also land them in a world of pain. I wouldn't want Twitter to endorse any product that wasn't theirs, and I doubt they would want to either. Too risky. -Stuart On Feb 4, 8:57 pm, Alex Payne a...@twitter.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. funkatron wrote: Agreed. I do believe that the use of HTTP Basic Auth was key to the quick growth of the 3rd-party app community of Twitter, as the auth scheme is so well-understood and supported. This may or may not be as important at this point business-wise, as I suspect the Twitter userbase is large enough to overcome a fair bit of lazy user intertia. I wonder if we will see a lot less interesting API hacking (the good kind), though, and I think that would be a shame. While OAuth makes a ton of sense for website-based apps, it's kind of another kettle of fish for locally-hosted apps (desktop and mobile). Moving to OAuth-only is problematic for us for these reasons: 1. it complicates (and confuses) the process for users: instead of entering a username and password -- a well-understood, common process -- now the app has to push the user to a web site which hopefully explains what's going on decently. This works okay for web dorks like us, but I guarantee your avg user is going to find this confusing. Maybe not as confusing as OpenID, though. 2. updating locally-hosted apps to use a new authentication system is an issue of getting thousands (or higher orders) of users to upgrade. 6 months may not be enough, even for currently active applications. Stuff in development *cough*like mine*cough* now could find themselves having to toss out a ton of code they're knee-deep in right now. Yucky. My preference would be to *not* see HTTP Basic Auth go away in the foreseeable future. If that's not reasonable or possible, the 6-month window (even given that the countdown may not start for a few months) is pretty tight for comfort, and extending it would be much preferred. Note: One might wonder why I only mention these issues in the context of local apps rather than web apps. I think the expectations and user behavior tendencies are fairly different in the desktop and mobile app space, and there are a number of ways malware is detected and contained in this area. The web app space is a lot more open and easy to exploit, and likely will be unless the whole paradigm changes. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 4, 10:03 pm, Cameron Kaiserspec...@floodgap.com wrote: I'm still (softly) repeating the hope that this will be extended, even if the Basic Auth API remains deprecated and static. An OAuth workflow is constrained for desktop apps, and for apps that aren't or can't use a web browser (in my case, text-mode twitter clients; other cases include all those little curl scripts posting monitoring information, task status, etc.), OAuth won't work at all. I fully support OAuth, but where appropriate. I think Ed Finkler said it best when he said the breadth of Twitter applications currently extant wouldn't exist were it not for a low barrier to entry. OAuth makes sense in many places, but it doesn't make sense everywhere, and I hope alternate methods of authentication remain possible even if they are intentionally limited to steer preferred traffic to an OAuth
Re: How API will works after OAuth?
2009/2/5 jstrellner jstrell...@urltrends.com: I am not suggesting that they endorse the application, but that they have a process that is available to desktop apps that lets them keep using Basic Auth. Once twitter has OK'd the app, then that app can display a badge of some sort letting its users know that they have an agreement directly with Twitter that makes it OK to enter your username/password. I would think that part of the process of approval would include a contract of some sort that specifies exactly what the app can do with that data. For a free service? Not very likely. It would be prohibitively expensive for Twitter to implement something where they underwrite a trust relationship between users and application developers. If application developers had to pay for it then maybe there is scope for that to be put in place, but doing so would exclude the vast majority of devs working with the API. Personally I'd vote for users being able to manually request a token which they then provide to the application. That effectively bypasses the OAuth authorisation mechanism while still providing many of the same benefits. Each key would need to be tied to the application in some way so it couldn't be shared, but I'm sure there's a solution in there somewhere. -Stuart On Feb 5, 8:48 am, Stuart stut...@gmail.com wrote: 2009/2/5 jstrellner jstrell...@urltrends.com: I was just thinking this, and then I read your post. It would be good to see a trusted apps section somewhere on your site, and those application could use Basic Auth. If they don't want to go through the process of being a trusted app, then they can use OAuth. Just something to think about. Could earn twitter some $$$ too. Could also land them in a world of pain. I wouldn't want Twitter to endorse any product that wasn't theirs, and I doubt they would want to either. Too risky. -Stuart On Feb 4, 8:57 pm, Alex Payne a...@twitter.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. funkatron wrote: Agreed. I do believe that the use of HTTP Basic Auth was key to the quick growth of the 3rd-party app community of Twitter, as the auth scheme is so well-understood and supported. This may or may not be as important at this point business-wise, as I suspect the Twitter userbase is large enough to overcome a fair bit of lazy user intertia. I wonder if we will see a lot less interesting API hacking (the good kind), though, and I think that would be a shame. While OAuth makes a ton of sense for website-based apps, it's kind of another kettle of fish for locally-hosted apps (desktop and mobile). Moving to OAuth-only is problematic for us for these reasons: 1. it complicates (and confuses) the process for users: instead of entering a username and password -- a well-understood, common process -- now the app has to push the user to a web site which hopefully explains what's going on decently. This works okay for web dorks like us, but I guarantee your avg user is going to find this confusing. Maybe not as confusing as OpenID, though. 2. updating locally-hosted apps to use a new authentication system is an issue of getting thousands (or higher orders) of users to upgrade. 6 months may not be enough, even for currently active applications. Stuff in development *cough*like mine*cough* now could find themselves having to toss out a ton of code they're knee-deep in right now. Yucky. My preference would be to *not* see HTTP Basic Auth go away in the foreseeable future. If that's not reasonable or possible, the 6-month window (even given that the countdown may not start for a few months) is pretty tight for comfort, and extending it would be much preferred. Note: One might wonder why I only mention these issues in the context of local apps rather than web apps. I think the expectations and user behavior tendencies are fairly different in the desktop and mobile app space, and there are a number of ways malware is detected and contained in this area. The web app space is a lot more open and easy to exploit, and likely will be unless the whole paradigm changes. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 4, 10:03 pm, Cameron Kaiserspec...@floodgap.com wrote: I'm still (softly) repeating the hope that this will be extended, even if the Basic Auth API remains deprecated and static. An OAuth workflow is constrained for desktop apps, and for apps that aren't or can't use a web browser (in my case, text-mode twitter clients; other cases include all those little curl scripts posting monitoring information, task status, etc.), OAuth won't work at all. I fully
search.json returning funky data
I have been making my usual search.json requests w/ my apps today, and all the sudden I am seeing these types of responses: Request URL: http://search.twitter.com/search.json?callback=search_func2q=jazzychadrpp=20since_id=1180576890rand=5736910 Response: callback_func(esi:include src=/search.json?q=jazzychadrpp=20since_id=1180576890/); Anyone else seeing this? Here are the headers... apologies for FireBug semi-mangling the output. Response Headers Date Thu, 05 Feb 2009 19:19:27 GMT Server hi Status 200 OK Etag b297b89210de5dd868c6dcd14d2df418-gzip Cache-Control max-age=20, must-revalidate, max-age=300 Content-Type application/json; charset=utf-8 X-Served-By searchweb005.twitter.com Expires Thu, 05 Feb 2009 19:24:27 GMT Content-Encoding gzip Content-Length 109 Vary Accept-Encoding X-Varnish 1220807190 Age 0 Via 1.1 varnish X-Cache-Svr searchweb005.twitter.com X-Cache MISS Connection close Request Headers Host search.twitter.com User-Agent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0 .12 Accept */* Accept-Language en-us,en;q=0.5 Accept-Encoding gzip,deflate Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive 300 Connection keep-alive Referer http://tweetgrid.com/grid?l=2
Re: How API will works after OAuth?
Stuart , In my first reply to this subject, I indicated that it could be a paid model for them, and I still think it could. Either way, I see them needing to use a key of some sort for desktop applications. Twitter would still need to be involved though, if you want to prevent sharing of said key and you want the user to be able to revoke it. -Joel On Feb 5, 11:48 am, Stuart stut...@gmail.com wrote: 2009/2/5 jstrellner jstrell...@urltrends.com: I am not suggesting that they endorse the application, but that they have a process that is available to desktop apps that lets them keep using Basic Auth. Once twitter has OK'd the app, then that app can display a badge of some sort letting its users know that they have an agreement directly with Twitter that makes it OK to enter your username/password. I would think that part of the process of approval would include a contract of some sort that specifies exactly what the app can do with that data. For a free service? Not very likely. It would be prohibitively expensive for Twitter to implement something where they underwrite a trust relationship between users and application developers. If application developers had to pay for it then maybe there is scope for that to be put in place, but doing so would exclude the vast majority of devs working with the API. Personally I'd vote for users being able to manually request a token which they then provide to the application. That effectively bypasses the OAuth authorisation mechanism while still providing many of the same benefits. Each key would need to be tied to the application in some way so it couldn't be shared, but I'm sure there's a solution in there somewhere. -Stuart On Feb 5, 8:48 am, Stuart stut...@gmail.com wrote: 2009/2/5 jstrellner jstrell...@urltrends.com: I was just thinking this, and then I read your post. It would be good to see a trusted apps section somewhere on your site, and those application could use Basic Auth. If they don't want to go through the process of being a trusted app, then they can use OAuth. Just something to think about. Could earn twitter some $$$ too. Could also land them in a world of pain. I wouldn't want Twitter to endorse any product that wasn't theirs, and I doubt they would want to either. Too risky. -Stuart On Feb 4, 8:57 pm, Alex Payne a...@twitter.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. funkatron wrote: Agreed. I do believe that the use of HTTP Basic Auth was key to the quick growth of the 3rd-party app community of Twitter, as the auth scheme is so well-understood and supported. This may or may not be as important at this point business-wise, as I suspect the Twitter userbase is large enough to overcome a fair bit of lazy user intertia. I wonder if we will see a lot less interesting API hacking (the good kind), though, and I think that would be a shame. While OAuth makes a ton of sense for website-based apps, it's kind of another kettle of fish for locally-hosted apps (desktop and mobile). Moving to OAuth-only is problematic for us for these reasons: 1. it complicates (and confuses) the process for users: instead of entering a username and password -- a well-understood, common process -- now the app has to push the user to a web site which hopefully explains what's going on decently. This works okay for web dorks like us, but I guarantee your avg user is going to find this confusing. Maybe not as confusing as OpenID, though. 2. updating locally-hosted apps to use a new authentication system is an issue of getting thousands (or higher orders) of users to upgrade. 6 months may not be enough, even for currently active applications. Stuff in development *cough*like mine*cough* now could find themselves having to toss out a ton of code they're knee-deep in right now. Yucky. My preference would be to *not* see HTTP Basic Auth go away in the foreseeable future. If that's not reasonable or possible, the 6-month window (even given that the countdown may not start for a few months) is pretty tight for comfort, and extending it would be much preferred. Note: One might wonder why I only mention these issues in the context of local apps rather than web apps. I think the expectations and user behavior tendencies are fairly different in the desktop and mobile app space, and there are a number of ways malware is detected and contained in this area. The web app space is a lot more open and easy to exploit, and likely will be unless the whole paradigm changes. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 4, 10:03
Re: search.json returning funky data
Sorry, I made have been confusing... in my example I made a typo which could distract from the actual issue. The callback is being named correctly in the response, but the data inside of it is what is concerning: esi:include src=/search.json?q=jazzychadrpp=20since_id=1180576890/ -Chad On Thu, Feb 5, 2009 at 2:59 PM, dougw igu...@gmail.com wrote: Chad, Not seeing it but I'm not making callback requests ... just straight .json requests. @dougw On Feb 5, 2:49 pm, Chad Etzel jazzyc...@gmail.com wrote: I have been making my usual search.json requests w/ my apps today, and all the sudden I am seeing these types of responses: Request URL:http://search.twitter.com/search.json?callback=search_func2q=jazzych... Response: callback_func(esi:include src=/search.json?q=jazzychadrpp=20since_id=1180576890/); Anyone else seeing this? Here are the headers... apologies for FireBug semi-mangling the output. Response Headers Date Thu, 05 Feb 2009 19:19:27 GMT Server hi Status 200 OK Etag b297b89210de5dd868c6dcd14d2df418-gzip Cache-Control max-age=20, must-revalidate, max-age=300 Content-Type application/json; charset=utf-8 X-Served-By searchweb005.twitter.com Expires Thu, 05 Feb 2009 19:24:27 GMT Content-Encoding gzip Content-Length 109 Vary Accept-Encoding X-Varnish 1220807190 Age 0 Via 1.1 varnish X-Cache-Svr searchweb005.twitter.com X-Cache MISS Connection close Request Headers Host search.twitter.com User-Agent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0 .12 Accept */* Accept-Language en-us,en;q=0.5 Accept-Encoding gzip,deflate Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive 300 Connection keep-alive Referer http://tweetgrid.com/grid?l=2
Re: search.json returning funky data
Hi Chad, We were rolling out a new cache layer to guard against some abuse cases and this might have been during the roll out. Are you still seeing the esi:include stuff? If so please let me know and we'll turn irt off. If not then you can expect less search rate limiting and improved response times in the near future. Thanks; — Matt Sanford On Feb 5, 2009, at 11:49 AM, Chad Etzel wrote: I have been making my usual search.json requests w/ my apps today, and all the sudden I am seeing these types of responses: Request URL: http://search.twitter.com/search.json?callback=search_func2q=jazzychadrpp=20since_id=1180576890rand=5736910 Response: callback_func(esi:include src=/search.json?q=jazzychadrpp=20since_id=1180576890/); Anyone else seeing this? Here are the headers... apologies for FireBug semi-mangling the output. Response Headers Date Thu, 05 Feb 2009 19:19:27 GMT Server hi Status 200 OK Etag b297b89210de5dd868c6dcd14d2df418-gzip Cache-Control max-age=20, must-revalidate, max-age=300 Content-Type application/json; charset=utf-8 X-Served-By searchweb005.twitter.com Expires Thu, 05 Feb 2009 19:24:27 GMT Content-Encoding gzip Content-Length 109 Vary Accept-Encoding X-Varnish 1220807190 Age 0 Via 1.1 varnish X-Cache-Svr searchweb005.twitter.com X-Cache MISS Connection close Request Headers Host search.twitter.com User-Agent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0 .12 Accept */* Accept-Language en-us,en;q=0.5 Accept-Encoding gzip,deflate Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive 300 Connection keep-alive Referer http://tweetgrid.com/grid?l=2
Re: search.json returning funky data
Hi Matt, Thanks for the quick response. Yes, I'm still seeing it (8 such errors in the last 3 minutes), but I don't want to mess up your upgrade timeline... my app handles the error cases like these, so it's not adversely affecting functionality, I was just surprised by FireBug reporting more and more errors on the page... -Chad On Thu, Feb 5, 2009 at 3:05 PM, Matt Sanford m...@twitter.com wrote: Hi Chad, We were rolling out a new cache layer to guard against some abuse cases and this might have been during the roll out. Are you still seeing the esi:include stuff? If so please let me know and we'll turn irt off. If not then you can expect less search rate limiting and improved response times in the near future. Thanks; — Matt Sanford On Feb 5, 2009, at 11:49 AM, Chad Etzel wrote: I have been making my usual search.json requests w/ my apps today, and all the sudden I am seeing these types of responses: Request URL: http://search.twitter.com/search.json?callback=search_func2q=jazzychadrpp=20since_id=1180576890rand=5736910 Response: callback_func(esi:include src=/search.json?q=jazzychadrpp=20since_id=1180576890/); Anyone else seeing this? Here are the headers... apologies for FireBug semi-mangling the output. Response Headers Date Thu, 05 Feb 2009 19:19:27 GMT Server hi Status 200 OK Etag b297b89210de5dd868c6dcd14d2df418-gzip Cache-Control max-age=20, must-revalidate, max-age=300 Content-Type application/json; charset=utf-8 X-Served-By searchweb005.twitter.com Expires Thu, 05 Feb 2009 19:24:27 GMT Content-Encoding gzip Content-Length 109 Vary Accept-Encoding X-Varnish 1220807190 Age 0 Via 1.1 varnish X-Cache-Svr searchweb005.twitter.com X-Cache MISS Connection close Request Headers Host search.twitter.com User-Agent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0 .12 Accept */* Accept-Language en-us,en;q=0.5 Accept-Encoding gzip,deflate Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive 300 Connection keep-alive Referer http://tweetgrid.com/grid?l=2
Re: search.json returning funky data
Hello again, We have the new code on one host to look for these kinds of errors, so thanks for the report. I'm trying to reproduce and I haven't yet been able to. I'll keep looking into it and if needs be take it out of production. There is no reason you should be seeing the esi:include/ tag. Thanks; — Matt Sanford On Feb 5, 2009, at 12:10 PM, Chad Etzel wrote: Hi Matt, Thanks for the quick response. Yes, I'm still seeing it (8 such errors in the last 3 minutes), but I don't want to mess up your upgrade timeline... my app handles the error cases like these, so it's not adversely affecting functionality, I was just surprised by FireBug reporting more and more errors on the page... -Chad On Thu, Feb 5, 2009 at 3:05 PM, Matt Sanford m...@twitter.com wrote: Hi Chad, We were rolling out a new cache layer to guard against some abuse cases and this might have been during the roll out. Are you still seeing the esi:include stuff? If so please let me know and we'll turn irt off. If not then you can expect less search rate limiting and improved response times in the near future. Thanks; — Matt Sanford On Feb 5, 2009, at 11:49 AM, Chad Etzel wrote: I have been making my usual search.json requests w/ my apps today, and all the sudden I am seeing these types of responses: Request URL: http://search.twitter.com/search.json?callback=search_func2q=jazzychadrpp=20since_id=1180576890rand=5736910 Response: callback_func(esi:include src=/search.json?q=jazzychadrpp=20since_id=1180576890/); Anyone else seeing this? Here are the headers... apologies for FireBug semi-mangling the output. Response Headers Date Thu, 05 Feb 2009 19:19:27 GMT Server hi Status 200 OK Etag b297b89210de5dd868c6dcd14d2df418-gzip Cache-Control max-age=20, must-revalidate, max-age=300 Content-Type application/json; charset=utf-8 X-Served-By searchweb005.twitter.com Expires Thu, 05 Feb 2009 19:24:27 GMT Content-Encoding gzip Content-Length 109 Vary Accept-Encoding X-Varnish 1220807190 Age 0 Via 1.1 varnish X-Cache-Svr searchweb005.twitter.com X-Cache MISS Connection close Request Headers Host search.twitter.com User-Agent Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080207 Ubuntu/7.10 (gutsy) Firefox/2.0.0 .12 Accept */* Accept-Language en-us,en;q=0.5 Accept-Encoding gzip,deflate Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive 300 Connection keep-alive Referer http://tweetgrid.com/grid?l=2
Anyone want to write this app?
I don't have time right now to do this, so I thought I'd pass it on and see if anyone else is interested. If so, please unicast me and I can get you the contact info for the person below. And yes, I know about Twitter Karma, but he says he's tried it and it didn't exactly accomplish his goals... -Chad Begin forwarded message: There are actually two things i'd like to be able to do 1. Make it easy to unfollow a ton of the folks i'm following in one shot. So...ideal world...i can import all of the folks i'm following into one web page. Then I could, just like in excel, click one...scroll downclick on another...all the ones inbetween would be highlighted...and I could unfollow all of those at once. 2. Go to any person's followers list...import them all at once...and then click one...scroll downclick on anotherall the one's inbetween would be highlighted, and then I could follow them all at once. For this...I believe you would have to 'throttle' how fast it followed those folks so there weren't any 'issues'. You may know more about that then I would. I wouldn't try to follow more then 3-5 hundred on any given day...as I heard past that you may run into 'issues'. Let me know how hard the above would be to create, and how much it would cost for me to have it created.
Re: New API methods to retrieve social graph without pagination
Hey Alex, any chance of adding a way of looking up the user name to the search api instead then? On Feb 5, 6:19 pm, Alex Payne a...@twitter.com wrote: The reason why we can provide the list of IDs without any pagination is that it comes directly from our denormalized list data store, and requires no joining, either in SQL or at the application layer. As soon as we pull in data like screen_name that's sitting elsewhere in our architecture, the response time slows down drastically. So while I do understand that it'd be more convenient, my hunch is that the quality of service for such a method would be intolerable. dougw wrote: For all those wanting id AND username attributes to be returned with these new methods, be sure to head over to http://code.google.com/p/twitter-api/issues/detail?id=265and vote (click the star) to signal your support. @dougw On Feb 5, 11:40 am, jstrellnerjstrell...@urltrends.com wrote: Thanks Alex, I too, would like to see this return userids AND usernames. -Joel On Feb 3, 5:01 pm, Alex Paynea...@twitter.com wrote: Happy to announce two new API methods today, delivered in response to developer demand for an easier way to keep tabs on users' social graphs. The methods, /friends/ids and /followers/ids, return the entire list of numeric user IDs for a user's set of followed and following users, respectively. Responses to these methods are cached until the user's social graph changes. The responses come direct from our denormalized list data stores, and should be reasonably fast even for users with a large number of followers/follows. These new methods are most useful for services that are maintaining a cache of user details. If you see a user ID that you don't have cached, you'll have to call /users/show to retrieve that user's details. But for services with large user bases, or those that simply want to diff a user's social graph over time, we hope these methods will come in handy. You can find the documentation athttp://apiwiki.twitter.com/REST-API-Documentation#SocialGraphMethods. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x
Re: New API methods to retrieve social graph without pagination
You can presently look up usernames in the Search API. What in particular are you looking for? Ninjamonk wrote: Hey Alex, any chance of adding a way of looking up the user name to the search api instead then? On Feb 5, 6:19 pm, Alex Paynea...@twitter.com wrote: The reason why we can provide the list of IDs without any pagination is that it comes directly from our denormalized list data store, and requires no joining, either in SQL or at the application layer. As soon as we pull in data like screen_name that's sitting elsewhere in our architecture, the response time slows down drastically. So while I do understand that it'd be more convenient, my hunch is that the quality of service for such a method would be intolerable. dougw wrote: For all those wanting id AND username attributes to be returned with these new methods, be sure to head over to http://code.google.com/p/twitter-api/issues/detail?id=265and vote (click the star) to signal your support. @dougw On Feb 5, 11:40 am, jstrellnerjstrell...@urltrends.comwrote: Thanks Alex, I too, would like to see this return userids AND usernames. -Joel On Feb 3, 5:01 pm, Alex Paynea...@twitter.comwrote: Happy to announce two new API methods today, delivered in response to developer demand for an easier way to keep tabs on users' social graphs. The methods, /friends/ids and /followers/ids, return the entire list of numeric user IDs for a user's set of followed and following users, respectively. Responses to these methods are cached until the user's social graph changes. The responses come direct from our denormalized list data stores, and should be reasonably fast even for users with a large number of followers/follows. These new methods are most useful for services that are maintaining a cache of user details. If you see a user ID that you don't have cached, you'll have to call /users/show to retrieve that user's details. But for services with large user bases, or those that simply want to diff a user's social graph over time, we hope these methods will come in handy. You can find the documentation athttp://apiwiki.twitter.com/REST-API-Documentation#SocialGraphMethods. -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: Anyone want to write this app?
Chad Etzel wrote: I don't have time right now to do this, so I thought I'd pass it on and see if anyone else is interested. If so, please unicast me and I can get you the contact info for the person below. And yes, I know about Twitter Karma, but he says he's tried it and it didn't exactly accomplish his goals... Of course it didn't. The stated goals is exactly what the make money on Twitter idiots are doing. See: For this...I believe you would have to 'throttle' how fast it followed those folks so there weren't any 'issues'. You may know more about that then I would. I wouldn't try to follow more then 3-5 hundred on any given day...as I heard past that you may run into 'issues'. I already hate the fact that Twitter spammers are using Twitter Karma, but I haven't figured out a way to determine if the user's one of those or a legitimate user, yet. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: Anyone want to write this app?
Andrew Badera wrote: Yeah, these requirements sound pretty spammy. 1. Follow a lot of people on Twitter. 2. Wait for people to follow you back. 3. ??? 4. PROFIT! You know, @DaveRhodes is SO underutilized. I'm sure he could tweet all day about how to MAKE MONEY FAST. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Parsing Direct Message emails
I'm using PHP to parse Twitter emails sent regarding Direct Messages. I've noticed that these come with footer text added on by Twitter (follow me at, reply on the web, etc). Right now, I just look for the last instance of the string segment -- and trim whatever text is contained within the email body from that point. However, I've noticed that just above the footer Twitter adds the senders username, like so: username / username. I'm currently grabbing the following information from the emails header: X-Twittersendername and X-Twittersenderscreenname, and working under the assumption that this string is essentially: X-Twittersendername / X-Twittersenderscreenname After that, I'm just using str_replace to strip away that text and then trim the resulting body text to get _just_ the DM contents. But what's the difference between the two values? I'm just wondering if I'm acting correctly, or if there's an easier way to do this. Note, however, that I'm not interested in grabbing the 20 latest DMs, and would instead prefer to remain parsing the emails sent by Twitter.
Re: How API will works after OAuth?
Flickr doesn't seem to have a problem with the OAuth formula, so why are people thinking twitter will? In addition, part of the concern I would have with Basic Auth is the plaintext password. Sure, it's Base64 encoded, but that's not encryption, that's just saving bandwidth. If twitter wanted to move to a different auth scheme, that might work. Or they could add ssl to the API front end, and use HTTPS, which is also expensive (either expensive SSL-offloading proxies, or you have to lock a session to a server). I don't think Twitter should keep a Basic Auth service. It just wouldn't be worth the risk to me. JD On Thu, Feb 5, 2009 at 12:02 PM, jstrellner jstrell...@urltrends.comwrote: Stuart , In my first reply to this subject, I indicated that it could be a paid model for them, and I still think it could. Either way, I see them needing to use a key of some sort for desktop applications. Twitter would still need to be involved though, if you want to prevent sharing of said key and you want the user to be able to revoke it. -Joel On Feb 5, 11:48 am, Stuart stut...@gmail.com wrote: 2009/2/5 jstrellner jstrell...@urltrends.com: I am not suggesting that they endorse the application, but that they have a process that is available to desktop apps that lets them keep using Basic Auth. Once twitter has OK'd the app, then that app can display a badge of some sort letting its users know that they have an agreement directly with Twitter that makes it OK to enter your username/password. I would think that part of the process of approval would include a contract of some sort that specifies exactly what the app can do with that data. For a free service? Not very likely. It would be prohibitively expensive for Twitter to implement something where they underwrite a trust relationship between users and application developers. If application developers had to pay for it then maybe there is scope for that to be put in place, but doing so would exclude the vast majority of devs working with the API. Personally I'd vote for users being able to manually request a token which they then provide to the application. That effectively bypasses the OAuth authorisation mechanism while still providing many of the same benefits. Each key would need to be tied to the application in some way so it couldn't be shared, but I'm sure there's a solution in there somewhere. -Stuart On Feb 5, 8:48 am, Stuart stut...@gmail.com wrote: 2009/2/5 jstrellner jstrell...@urltrends.com: I was just thinking this, and then I read your post. It would be good to see a trusted apps section somewhere on your site, and those application could use Basic Auth. If they don't want to go through the process of being a trusted app, then they can use OAuth. Just something to think about. Could earn twitter some $$$ too. Could also land them in a world of pain. I wouldn't want Twitter to endorse any product that wasn't theirs, and I doubt they would want to either. Too risky. -Stuart On Feb 4, 8:57 pm, Alex Payne a...@twitter.com wrote: Thanks for the feedback, guys. We'll consider extending Basic Auth's life, or maybe granting a stay of execution to known-good apps. At the very least, we'll try not to pull the rug out from under anyone. funkatron wrote: Agreed. I do believe that the use of HTTP Basic Auth was key to the quick growth of the 3rd-party app community of Twitter, as the auth scheme is so well-understood and supported. This may or may not be as important at this point business-wise, as I suspect the Twitter userbase is large enough to overcome a fair bit of lazy user intertia. I wonder if we will see a lot less interesting API hacking (the good kind), though, and I think that would be a shame. While OAuth makes a ton of sense for website-based apps, it's kind of another kettle of fish for locally-hosted apps (desktop and mobile). Moving to OAuth-only is problematic for us for these reasons: 1. it complicates (and confuses) the process for users: instead of entering a username and password -- a well-understood, common process -- now the app has to push the user to a web site which hopefully explains what's going on decently. This works okay for web dorks like us, but I guarantee your avg user is going to find this confusing. Maybe not as confusing as OpenID, though. 2. updating locally-hosted apps to use a new authentication system is an issue of getting thousands (or higher orders) of users to upgrade. 6 months may not be enough, even for currently active applications. Stuff in development *cough*like mine*cough* now could find themselves having to toss out a ton of code they're knee-deep in right now. Yucky. My preference would be to *not* see HTTP Basic
Re: How API will works after OAuth?
On Feb 5, 10:38 pm, James Deville james.devi...@gmail.com wrote: Flickr doesn't seem to have a problem with the OAuth formula, so why are people thinking twitter will? I'm not sure people have said Twitter would have a problem. I've personally expressed some problems specific to applications I develop. Much of what I said would apply to desktop apps for Flickr too, but Flickr has never offered anything but OAuth (AFAIK). In addition, part of the concern I would have with Basic Auth is the plaintext password. Sure, it's Base64 encoded, but that's not encryption, that's just saving bandwidth. If twitter wanted to move to a different auth scheme, that might work. Or they could add ssl to the API front end, and use HTTPS, which is also expensive (either expensive SSL-offloading proxies, or you have to lock a session to a server). I don't think Twitter should keep a Basic Auth service. It just wouldn't be worth the risk to me. SSL has been available in the API for as long as I recall, and is in fact officially recommended, AFAIK. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron
Re: How API will works after OAuth?
On Thu, Feb 5, 2009 at 7:52 PM, funkatron funkat...@gmail.com wrote: On Feb 5, 10:38 pm, James Deville james.devi...@gmail.com wrote: Flickr doesn't seem to have a problem with the OAuth formula, so why are people thinking twitter will? I'm not sure people have said Twitter would have a problem. I've personally expressed some problems specific to applications I develop. Much of what I said would apply to desktop apps for Flickr too, but Flickr has never offered anything but OAuth (AFAIK). I thought I had read that concern earlier in the thread. In addition, part of the concern I would have with Basic Auth is the plaintext password. Sure, it's Base64 encoded, but that's not encryption, that's just saving bandwidth. If twitter wanted to move to a different auth scheme, that might work. Or they could add ssl to the API front end, and use HTTPS, which is also expensive (either expensive SSL-offloading proxies, or you have to lock a session to a server). I don't think Twitter should keep a Basic Auth service. It just wouldn't be worth the risk to me. SSL has been available in the API for as long as I recall, and is in fact officially recommended, AFAIK. Didn't realize that... (Off to the editor...) -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron
