Tim, sorry for taking so long to follow up. Responses inline below...

--
Ryan Sarver
@rsarver <http://twitter.com/rsarver>



On Mon, Mar 14, 2011 at 4: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.
>

I understand that for the purposes of this email you are considering Favstar
a client, but it doesn't actually fall within the description of a client --
even if you add the ability to tweet. You are not focused on solely
rendering the user's home_timeline to them. Obviously, it is difficult to
nail down the exact requirements that make it a client, but we're happy to
work with developers to figure out where the lines are. So with that being
said, it's going to be hard to answer hypothetical questions, but I'll do my
best by trying to understand your intention.


>
>
> 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?
>

If you were a client, yes


>
> *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?
>

This is obviously a fine line. The value of trending topics is that the
community of users can aggregate around timely conversations as they happen.
If this gets too fractured it loses the value of the network effect. So
again, if you were a client, then yes. If you stay focused on offering
something differentiated, then no.


>
> *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?
>

We would need to review it as this is a fairly complex comparison.


>
> 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?
>

we had seen a number of twitter "clients" create an iOS shim and then just
frame m.twitter.com and charge for the app. that is not awesome


>
> 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?
>

We are aware of the lack of deletion notices via REST API. We ask partners
to respect the notices they are given, but you obviously can't delete
something you don't know has been deleted. If a user protects their profile,
then you also need to mirror and respect that on your site. I'm clear who
you are referring to when you mean it would anger your users.


>
> 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.
>

correct. you are fine to cross post. We don't want you to build your own
statuses network and content coming from twitter to build it up. This comes
back to the user. If they are aware and choose to post to a number of
networks, then we totally support that. But a user just posting to Twitter
doesn't know their content is helping create another network and that's not
their expectation.


>
> *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?
>

Not sure what you mean here. My guess is that it's not. I assume you know
what is intended here.


>
> *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?
>

Hopefully my answer to your previous question cleared this up as well.

Managing the governance around an ecosystem, especially as large as
Twitter's, is complex and there are rarely black and white answers. We
strive to be as clear, concise and transparent as possible but we can always
improve. Please feel free to ask questions and we'll clarify as much as we
can.

Unfortunately there are bad actors out there that force our hand in adding
more rules and complexity, but that is one of the truisms of growth. Most
developers are not only good actors, but have great intentions and add a lot
of value for users. We obviously want to optimize for them, but we need to
protect users and the platform from the bad ones.

Hope this all helps clarify.

Best, Ryan


>
>
> 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