Tim, thanks for taking the time to write up such an epic email. Give me some time to parse through it so I can follow up on all the points.
Also, not sure what happened to the thread on api-announce, but I reposted linking to this thread so people can still find it. Best, Ryan -- Ryan Sarver @rsarver <http://twitter.com/rsarver> On Mon, Mar 14, 2011 at 11:39 PM, Tim Haines <tmhai...@gmail.com> wrote: > Hey Ryan, Raffi, Taylor, Matt, and other Twitter staff, > > I've been confused about Ryan's post, and some of the follow up comments. > Some of the tweets I've seen since have been reassuring that my original > interpretation of Ryan's email was inaccurate. I thought you were saying > 'no new client apps allowed', and I'm very relieved to hear I was wrong. > > I wanted to follow up with a few more questions and comments to make sure I > understand Twitter's message correctly. Twitter staff, if I have anything > wrong here, please correct, or rephrase to be more accurate. > > Please excuse the length of this and the number of questions at the end of > the email. Changing the API rules is changing the contract we have, and as > I'm so invested in the ecosystem (my family's livelihood now depends on it), > I want to be completely sure I understand what the new contract is that > you're introducing. > > First off, some background. Ryan said that developers are welcome to > develop things that Twitter has said developers shouldn't be doing - > "shouldn't" is guidance only, and not a prohibition. Twitter will > only interfere with applications if they break the API TOS. Tweets related > to this (clicking on the last one and viewing the thread is easiest): > > - https://twitter.com/joestump/status/47094929796759552 > - https://twitter.com/rsarver/status/47095346899320832 > - https://twitter.com/timhaines/status/47096379306291203 > - https://twitter.com/rsarver/status/47096690288771072 > - https://twitter.com/timhaines/status/47097497679708160 > - https://twitter.com/rsarver/status/47097681591545856 > > > Furthermore, the most disturbing paragraph for me in Ryan's announcement: > > If you are an existing developer of client apps, you can continue to serve >> your user base, but we will be holding you to high standards to ensure you >> do not violate users’ privacy, that you provide consistency in the user >> experience, and that you rigorously adhere to all areas of our Terms of >> Service. > > > This and the preceding paragraph together could be interpreted to mean that > developers "aren't allowed" to build NEW client apps. According to the > tweets above, they are allowed, but Twitter is advising developers that they > should focus their efforts elsewhere. Likewise, existing applications "will > be held to high standards". As Ryan clarified in his tweets, these > applications won't be interfered with unless they break the API TOS. So all > told, the email itself doesn't introduce anything new rulewise; you can do > anything you want within the API TOS, but if you break the API TOS you'll > potentially have your app revoked. No change here. > > You won't be applying a subjective 'high standard' or 'high bar' and > revoking an app unless it breaks the API TOS. Phew! You are remaining an > open API, within the confines of your stated rules. > > However, the email was accompanied with changes to the API TOS (of course > Twitter can make any change to the API TOS at any time - including adding > further restrictions in the future). This round of changes included amongst > other things, the addition of section I.5, adding restrictions to what > client applications may and may not do. For the purposes of this email, I'm > considering my own application, Favstar, a client. While it doesn't allow > you to tweet at the moment, it will in the coming months, therefore meeting > the criteria specified in the API TOS for Favstar to be regarded as a > client. > > > My questions: > > > 5a: 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. > > > *Question re 5a:* Favstar has for a long time offered 'suggested user > lists' in the form of it's popular page ( > http://favstar.fm/popular-on-twitter-by-tweets-with-50-favorites) Is this > feature now in breach of the API TOS? If it is in breach, does this place > Favstar in breach until the feature is removed? > > *Question re 5a:* If I was to add features that surfaced 'popular themes' > found in tweets that Favstar collects, would this be considered similar to > Trending topics, and put Favstar in breach of the API TOS? > > *Question re 5a:* Favstar users can buy 'bonus features', and receive a > slew of extra features. I've recently started promoting these users on the > site. If follow buttons were added to their avatar's in the places of > promotion, could this be considered as a 'who to follow' feature that would > put Favstar in breach of the API TOS? > > 5c: Your Client cannot frame or otherwise reproduce significant portions >> of the Twitter service. You should display Twitter Content from the Twitter >> API. > > > *Clarify Please re 5c:* This seems like it could be applied pretty > generally, and I'm not sure what what constitute a breach of it. Could you > provide some examples? > > 5d: Do not store non-public user profile data or content. > > > *Question re 5d:* Favstar collects and stores tweets that are favorited. > Some of those tweets are later deleted. If Favstar has an oauth token for > the user, their tweet will be deleted from Favstar also. However, if the > tweet has been collected via the fav REST API, it's possible that I don't > have an oauth token for the user, so I won't be notified of deletions, and > won't know when tweets have been deleted. Another scenario where this > applies is that users sometimes make their profiles protected for a short > time, and then unprotect them. Is it expect that when a user protects their > profile, all content for them should be removed? This would anger a lot of > my users, and cause an experience inconsistent with their expectations. > However, does not doing it put Favstar in breach of the API TOS? > > 5e: You may not use Twitter Content or other data collected from end users >> of your Client to create or maintain a separate status update or social >> network database or service. > > > *Interpretation re 5e - please confirm:* It's okay for me to collect a > 'status update' from the user, and to send it as content to Twitter, > Facebook, and Tumblr all at once. It's also okay for me to pull content > from all of those social networks and display them on Favstar, a Twitter > client. However, it's not okay for me to start tracking 'Favstar Status > Updates' as something the user could post without requiring them to publish > their content elsewhere. > > *Question re 5e:* I'm not permitted to create a social network service > from data I collect from end users of my client (Favstar). Is the Tweet of > the Day feature I offer a social network service? > > *Question re 5e:* I have many new features that I plan to introduce to > Favstar in 2011. How do I determine whether they will put me in breach of > 5e? Can you make it a little clearer what constitutes a 'separate status > update database/service or separate social network database/service'. > Please? > > > Thanks for taking the time to read through all of this. I look forward to > receiving your reply and having my concerns put to rest. > > Regards, > > Tim. > > -- > 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