I appreciate the healthy debate here over the issue, and we all read the threads in this forum, but the reality is we don't have the time to respond to every inquiry. Chad has done a great job in making sure explicit questions get answered and we are happy to have an open discussion about the topic.
Let me try to answer the myriad of topics that have been raised here: 1. Duplicate tweets HAS always been considered a violation. If you haven't read The Twitter Rules (clearly linked to from the Terms), you should read them now: http://help.twitter.com/forums/26257/entries/18311. It clearly states under *Spam* that the definition will include ... "post duplicate content over multiple accounts or multiple duplicate updates on one account" 2. In the Spam section of that policy we also clearly state that the rules will be changing as we adapt to new tactics. It's an arms race and we need the ability to react to new issues to protect the experience for all users and developers. And counter to Dewalds point, releasing exact numbers for spammers to circumvent creates MORE of an issue, not less. If you are dancing around the edges of those numbers, you are likely supporting functionality that questionable. 3. Spam is bad. For everyone. We will not only enforce the letter of that document but the spirit of that document. If your app enables spam, be prepared to get an email from us. We will help you identify the features that are facilitating spammy behavior and work with you to rectify it. 4. We are open with our policies and communication. If you have questions about your app, please email us for clarification. We are happy to talk to you about it. Best, Ryan On Tue, Oct 13, 2009 at 7:46 PM, Dewald Pretorius <dpr...@gmail.com> wrote: > > "I've previously asked for guidelines on what our responsibilities are > in terms of self-policing. No answer." > > Add to that the clear and unambiguous definition of things. Yeah sure, > "Twitter cannot clearly define things because that will aid the > spammers." Bullshit. It is their responsibility to define what exactly > is acceptable to them. That will not assist the spammers. It will > assist us to not inadvertently, through wrong interpretation or > assumption, provide a platform that spammers can leverage. > > Up until the first email I received from Twitter on October 8th, I was > monitoring the level of duplicate tweet rejection that the API was > giving, and I consequently concluded that the users of my service was > not producing a large amount of duplicate tweets. Seems like their > internal definition of duplicate content is far wider than the > interpretation of the Platform Team when they wrote the code to reject > duplicate tweets. > > I still do not know exactly what is "duplicate content" and what is > not. Do you? I guess not. Nobody knows. > > Dewald > > On Oct 13, 11:07 pm, PJB <pjbmancun...@gmail.com> wrote: > > Chad: > > > > Sorry, I didn't see you had posted in here, and not sure if my > > subsequent posts properly answered you. > > > > I mean that Desktop apps, not being bound by a whitelisted IP, > > wouldn't be limited by restrictions limiting API access to OAUTH > > only. Namely, a desktop client could use a Mozilla user-agent, scrape > > Twitter.com, grab an "authenticity_token", and then do a simple HTTP > > form submission with plaintext username/password. From there, the > > client could do whatever "outlawed" actions aren't possible from Web > > apps. > > > > While you could presumably find some commonalities with these logins > > for a time, probably the only effective way to counter this approach > > is to introduce login captchas. And that's an ugly barrier to entry > > for the average user. > > > > Restricting Web-based apps will presumably shift the policed behavior > > to such desktop apps, where it would probably morph into something > > even more destructive. > > > > As a web-based developer, I've previously asked for guidelines on what > > our responsibilities are in terms of self-policing. No answer. And > > it's really disheartening to hear that carte blanche limitations are > > now being imposed. > > > > There are obvious legitimate uses for recurring dynamic tweets (e.g., > > NBC announcing show schedules/guests, or fitness apps tweeting how > > many miles you ran). Blocking such behavior across the board seems > > incredibly short-sighted and limits further important business- > > oriented development in this area. > > > > PB > > > > On Oct 13, 12:47 pm, Chad Etzel <c...@twitter.com> wrote: > > > > > On Tue, Oct 13, 2009 at 3:38 PM, PJB <pjbmancun...@gmail.com> wrote: > > > > > > Wrong. Basic Authentication will obviously ALWAYS be an option for > > > > desktop clients, regardless of whether or not it is via API. > > > > > Please explain this statement? > > > -Chad > > > > > >> Furthermore, the app in question explicitly offered the option of a > > > >> recurring tweet which is a violation of the TOS. Regardless of > whether or > > > >> not that provides a useful service -- I'm not going to start > debating that > > > >> -- the fact of the matter is it *is* a violation of the TOS. Plain > and > > > >> simple. Why shouldn't they be "allowed" (as if we have a say what a > private > > > >> company does with their own resources) to ban an app that violates > the TOS > > > >> with one of their own options? > > > > > > I see, so then sites like mapmyrun and others that, for example, > tweet > > > > "Bob ran 10 miles today in 2 hours", "Bob ran 12 miles today in 1 > > > > hour", and other templated text, are also in violation of the terms? > > > > Or what about hootsuite where I can queue up 100 tweets with the > exact > > > > same text to fire off every hour, perhaps interspersed with a second > > > > tweet? > > > > > > The bottom line is that this situation isn't as black and white as > you > > > > think, and Twitter's approach is wrong-headed. >
