This document needs further detail, specifics, and allowances.
1. "Identify the user that authored or provided the Tweet" What do you mean by this? Presumably the author of the tweet is the person for whom the tweet appears on Twitter.com and who therefore actually made the tweet or authorized it, right? Isn't that sufficient? Or do you mean, say, that all those "vampire bite" tweets must identify that they come from vampiresRus.com (or wherever) IN THE TWEET ITSELF? Does a source parameter count as identification, or must the tweet itself contain separate identification along with the content of the tweet? 2. "Maintain the integrity of Tweets and not edit or revise them." Wait, we can edit tweets?! I think you need to be more precise with your language and definitions here. In my mind, a "tweet" is something that appears on Twitter.com, and isn't something which may soon appear on Twitter.com. If Barack Obama says a sentence, it isn't a tweet until it is on Twitter.com. Furthermore, you should get rid of the part where it says "edit or revise". It is sufficient to say integrity, particularly as new transformational tools come on line. For example, if a user queues up tweets and indicates that he wishes for them to be translated into Klingon prior to their tweeting, that does constitute "edits and revisions" to those tweets. But presumably this is acceptable as the user has approved such transformation. Similarly, I think you need to account for the fact that many applications allow the user to approve action-based Tweets where there is no actual "text" to approve. For example, the Firefox add-ons that let me tweet a particular URL, or one that lets me tweet stock trades I am making, etc. In these cases, I have approved the method to create the tweet (that I press a button and the URL and Title of the page I am on will be tweeted), but I haven't explicitly approved the text of that URL/title (nor would I want to go through that hassle). I would reword the section, then, as something like: "Maintain the integrity of the user-approved text to be tweeted, or the process by which the text to be tweeted is created; and do not edit or revise said text, except where the user has specifically approved such transformations." 3. "Get each user's consent before sending Tweets or other messages on their behalf. A user authenticating with your application does not constitute consent to send a message." Okay, so what DOES constitute consent? A checkbox that defaults to 'on' with the Tweet? Or a checkbox that defaults to 'off' and which the user can turn on? What about if the user agrees to a long small- type contract wherein it stipulates that the app can tweet on their behalf (yet which the user most likely hasn't fully read)? I think instead of defining what DOESN"T constitute consent, you should give examples of what does constitute consent. On Sep 10, 4:58 pm, Marcel Molina <[email protected]> wrote: > To accompany our updated Terms of Service (http://bit.ly/2ZXsyW) we've > posted a draft of the Twitter API rules athttp://twitter.com/apirules. As the > subject states, these rules are a > work in progress and feedback is welcome. Please read the TOS > announcement athttp://bit.ly/2ZXsyWfor some background. We encourage > you to use the "contact us" link athttp://twitter.com/apiruleswith > any feedback you may have. > > -- > Marcel Molina > Twitter Platform Teamhttp://twitter.com/noradio
