Bearing mind that I run tweekly.fm, some of this issues are of interest to me too.
On 14 Mar 2011, at 23:39, Tim Haines 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
