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

Reply via email to