Ryan, you said in another post in this thread that statuses/user_timeline is still allowed. I'm curious how that jives with your second sentence here, "It's apps that render a user their timeline."
What will happen if an app falls into a gray area of being a client or consumer client? Will we simply have our Oauth tokens revoked, or will there be some sort of review process? Will their be a deadline for current client-only apps to find a way to fit the new TOS? -Craig On 12 March 2011 19:47, Ryan Sarver <[email protected]> wrote: > Mike, a client is one that recreates the twitter experience, or in your > words the "primary" experience. So I don't consider Instagram or Foursquare > in that group. It's apps that render a user their timeline. > > Apps that post into Twitter are great and explicitly called out at the > bottom of the email. > > Hope that helps clarify. > > Best, Ryan > -- > Ryan Sarver > @rsarver <http://twitter.com/rsarver> > > > > On Fri, Mar 11, 2011 at 9:09 PM, Mike Champion <[email protected]>wrote: > >> Thanks for the clarification Ryan. Two questions: >> >> 1) Do you have a clear definition of what counts as a Twitter client? >> Is it any app/service that posts updates to Twitter, including apps >> like twitterfeed and Instapaper? Or is it only those apps that are >> "primarily" clients? I'm certainly familiar with the challenge of >> classifying apps ;) but wanted to know who will be covered by the ToS >> Section 1.5 and how you think about "clients" given Twitter's updated >> stance. >> >> 2) In section 1.5.A of the ToS it says: >> >> "Your Client must use the Twitter API as the sole source for features >> that are substantially similar to functionality offered by Twitter. >> Some examples include trending topics, who to follow, and suggested >> user lists." >> >> Is the "Who to follow" functionality available via API from Twitter >> for clients that want to offer this? I wasn't aware that it been >> released as API but may have missed it on dev.twitter.com. >> >> Thanks, >> >> -mike >> >> On Mar 11, 3:47 pm, Eric Mill <[email protected]> wrote: >> > "More specifically, developers ask us if they should build client apps >> that >> > mimic or reproduce the mainstream Twitter consumer client experience. >> The >> > answer is no." >> > >> > "We need to ensure users can interact with Twitter the same way >> everywhere." >> > >> > I'm not sure you can say these things and simultaneously try to say you >> have >> > a welcoming developer environment. All third party Twitter developers, >> no >> > matter what they make, are now walking on eggshells, constantly at risk >> of >> > offending Twitter's ideas of how users should interact with Twitter. >> > >> > You may feel you "need" this consistency, but you don't. You want it, >> and >> > are willing to make tradeoffs to get it. I just hope you realize how big >> > those tradeoffs are, and how chilling it is for Twitter to decide that >> only >> > certain kinds of innovation on the Twitter API are welcome. >> > >> > -- Eric >> >> -- >> Twitter developer documentation and resources: http://dev.twitter.com/doc >> API updates via Twitter: http://twitter.com/twitterapi >> Issues/Enhancements Tracker: >> http://code.google.com/p/twitter-api/issues/list >> Change your membership to this group: >> http://groups.google.com/group/twitter-development-talk >> > > -- > Twitter developer documentation and resources: http://dev.twitter.com/doc > API updates via Twitter: http://twitter.com/twitterapi > Issues/Enhancements Tracker: > http://code.google.com/p/twitter-api/issues/list > Change your membership to this group: > http://groups.google.com/group/twitter-development-talk > -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
