[twitter-dev] Twitter Streaming API Returning retweet_count and retweeted incorrectly?

[Sendhil]

Hey All,

I built a a small ruby app using the TweetStream gem to monitor a few hash 
tags on twitter and have had it running inside a daemon without a problem 
for a week or two.  Starting earlier this afternoon, for some reason, 
whenever a Tweet that's Retweeted comes in, the *retweeted_status* element 
will be there with the corresponding retweet data, but the value for *
retweeted* is always be false, and the value for *retweet_count* is always 
zero.  Any ideas on why this would be happening?

Thanks,
Sendhil

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

Re: [twitter-dev] Requesting increased access levels for Streaming API

[Scott Wilcox]

Yes, 350 requests per user, per hour.

On 17 Mar 2011, at 22:46, hank williams wrote:

> Thanks Taylor. So just to clarify, the 350 requests is per user
> account, not per server/ip address? We are creating a web application
> (not a desktop/mobile client) that will need to query account multiple
> times per hour. If the rate limits are per user account then we have
> no problem. If the rate limits are per server or ip address, and we
> even have a few dozen users then we would quickly be over the rate
> limit. Happy to use the REST API if that will work, though as we scale
> it likely means we will send many tens and then hundreds of thousands
> of requests per hour. The use case is that we are allowing people to
> backup their tweets (and other data types) and search them. Ultimately
> we will want to use site streams because we will waste a lot of
> processing power polling, but as long as the rate limits are per user
> account we are fine for now.
> 
> Regards,
> Hank
> 
> On Thu, Mar 17, 2011 at 6:36 PM, Taylor Singletary
>  wrote:
>> Hi Hank,
>> We believe it to be entirely possible to build a web-based Twitter client
>> using only the REST API without whitelisting. Where are you thinking that
>> you would require it? Site Streams makes it easier in some ways, though the
>> implementation can be more complicated and intensive.
>> By requiring that your end-users authenticate a Twitter account, you can
>> execute ~350 authenticated GET requests per hour on behalf of that user from
>> your server's IP address. There are 24 hours in a day. That's 8,400
>> authenticated GET requests you can make on their behalf per day, in which
>> you're fetching timelines for them, user profile metadata, and so on.
>> If there are specific actions you can't perform for a certain user within
>> 350 requests in a given hour, you queue the rest of the activity and ask the
>> user to wait until you can process the data for them.
>> Interested to know where a whitelisting requirement fits in with your use
>> case.
>> @episod - Taylor Singletary - Twitter Developer Advocate
>> 
>> 
>> On Thu, Mar 17, 2011 at 3:22 PM, hank williams  wrote:
>>> 
>>> Ryan,
>>> 
>>> I have asked this a few times, (every time you mention using site
>>> streams) and I realize everyone at twitter is really busy, but it
>>> would be really helpful to know whether it is possible to write
>>> twitter web based apps right now given that there is no whitelisting,
>>> and site streams seems to be in closed beta. It would seem without
>>> site streams, creating webapps that use twitter would be impossible.
>>> If there is some workaround that I don't know about, please let me
>>> know.
>>> 
>>> Thanks,
>>> Hank
>>> 
>>> On Thu, Mar 17, 2011 at 6:09 PM, Ryan Sarver  wrote:
 Ed, I'm not sure what you mean by: "You need to get *all* your users to
 *explicitly* authorize the application's *exact* usage of their data!"
 Of course! that is exactly what we are saying and I'm not sure if you're
 really saying you shouldn't get the user's authorization as that doesn't
 make sense.
 I don't expect everyone to be able to use User Streams or Site Streams,
 but
 that is why the REST API exists.
 
 --
 Ryan Sarver
 @rsarver
 
 
 On Wed, Mar 16, 2011 at 8:52 PM, M. Edward (Ed) Borasky
  wrote:
> 
> On Wed, 16 Mar 2011 09:10:13 -0700 (PDT), "Ryan Sarver (@rsarver)"
>  wrote:
>> 
>> Also as we stated before, you can use User Streams or Site Streams and
>> get more data by getting more users to authorize your application.
> 
> Ryan, it's not as simple as "getting more users to authorize your
> application." You need to get *all* your users to *explicitly*
> authorize the
> application's *exact* usage of their data! Users tend not to "read the
> fine
> print". I'd hate to see some data collection / analytics application
> make
> some assumptions based on the implicit openness of the tweet stream and
> then
> get nailed by a bunch of angry users. Angry users tend to write to
> their
> Congressmen and Senators. ;-)
> 
> Managing a *single* user's User Streams feed is a relatively
> straightforward coding task - I've got a smallish Perl script that can
> do it
> for my own account. Managing multiple users' Site Streams is a much
> more
> complex endeavor, and to use that mechanism for a data collection /
> analytics application is ludicrous IMHO. Somehow, the notion of "the
> right
> tool for the job" seems to have been ignored. ;-)
> 
> --
> http://twitter.com/znmeb http://borasky-research.net
> 
> "A mathematician is a device for turning coffee into theorems." -- Paul
> Erdős
> 
> --
> Twitter developer documentation and resources:
> http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker:

Re: [twitter-dev] Re: Requesting increased access levels for Streaming API

[hank williams]

Thanks Taylor. So just to clarify, the 350 requests is per user
account, not per server/ip address? We are creating a web application
(not a desktop/mobile client) that will need to query account multiple
times per hour. If the rate limits are per user account then we have
no problem. If the rate limits are per server or ip address, and we
even have a few dozen users then we would quickly be over the rate
limit. Happy to use the REST API if that will work, though as we scale
it likely means we will send many tens and then hundreds of thousands
of requests per hour. The use case is that we are allowing people to
backup their tweets (and other data types) and search them. Ultimately
we will want to use site streams because we will waste a lot of
processing power polling, but as long as the rate limits are per user
account we are fine for now.

Regards,
Hank

On Thu, Mar 17, 2011 at 6:36 PM, Taylor Singletary
 wrote:
> Hi Hank,
> We believe it to be entirely possible to build a web-based Twitter client
> using only the REST API without whitelisting. Where are you thinking that
> you would require it? Site Streams makes it easier in some ways, though the
> implementation can be more complicated and intensive.
> By requiring that your end-users authenticate a Twitter account, you can
> execute ~350 authenticated GET requests per hour on behalf of that user from
> your server's IP address. There are 24 hours in a day. That's 8,400
> authenticated GET requests you can make on their behalf per day, in which
> you're fetching timelines for them, user profile metadata, and so on.
> If there are specific actions you can't perform for a certain user within
> 350 requests in a given hour, you queue the rest of the activity and ask the
> user to wait until you can process the data for them.
> Interested to know where a whitelisting requirement fits in with your use
> case.
> @episod - Taylor Singletary - Twitter Developer Advocate
>
>
> On Thu, Mar 17, 2011 at 3:22 PM, hank williams  wrote:
>>
>> Ryan,
>>
>> I have asked this a few times, (every time you mention using site
>> streams) and I realize everyone at twitter is really busy, but it
>> would be really helpful to know whether it is possible to write
>> twitter web based apps right now given that there is no whitelisting,
>> and site streams seems to be in closed beta. It would seem without
>> site streams, creating webapps that use twitter would be impossible.
>> If there is some workaround that I don't know about, please let me
>> know.
>>
>> Thanks,
>> Hank
>>
>> On Thu, Mar 17, 2011 at 6:09 PM, Ryan Sarver  wrote:
>> > Ed, I'm not sure what you mean by: "You need to get *all* your users to
>> > *explicitly* authorize the application's *exact* usage of their data!"
>> > Of course! that is exactly what we are saying and I'm not sure if you're
>> > really saying you shouldn't get the user's authorization as that doesn't
>> > make sense.
>> > I don't expect everyone to be able to use User Streams or Site Streams,
>> > but
>> > that is why the REST API exists.
>> >
>> > --
>> > Ryan Sarver
>> > @rsarver
>> >
>> >
>> > On Wed, Mar 16, 2011 at 8:52 PM, M. Edward (Ed) Borasky
>> >  wrote:
>> >>
>> >> On Wed, 16 Mar 2011 09:10:13 -0700 (PDT), "Ryan Sarver (@rsarver)"
>> >>  wrote:
>> >>>
>> >>> Also as we stated before, you can use User Streams or Site Streams and
>> >>> get more data by getting more users to authorize your application.
>> >>
>> >> Ryan, it's not as simple as "getting more users to authorize your
>> >> application." You need to get *all* your users to *explicitly*
>> >> authorize the
>> >> application's *exact* usage of their data! Users tend not to "read the
>> >> fine
>> >> print". I'd hate to see some data collection / analytics application
>> >> make
>> >> some assumptions based on the implicit openness of the tweet stream and
>> >> then
>> >> get nailed by a bunch of angry users. Angry users tend to write to
>> >> their
>> >> Congressmen and Senators. ;-)
>> >>
>> >> Managing a *single* user's User Streams feed is a relatively
>> >> straightforward coding task - I've got a smallish Perl script that can
>> >> do it
>> >> for my own account. Managing multiple users' Site Streams is a much
>> >> more
>> >> complex endeavor, and to use that mechanism for a data collection /
>> >> analytics application is ludicrous IMHO. Somehow, the notion of "the
>> >> right
>> >> tool for the job" seems to have been ignored. ;-)
>> >>
>> >> --
>> >> http://twitter.com/znmeb http://borasky-research.net
>> >>
>> >> "A mathematician is a device for turning coffee into theorems." -- Paul
>> >> Erdős
>> >>
>> >> --
>> >> 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
>> >
>> > --
>> > T

Re: [twitter-dev] Re: Requesting increased access levels for Streaming API

[Taylor Singletary]

Hi Hank,

We believe it to be entirely possible to build a web-based Twitter client
using only the REST API without whitelisting. Where are you thinking that
you would require it? Site Streams makes it easier in some ways, though the
implementation can be more complicated and intensive.

By requiring that your end-users authenticate a Twitter account, you can
execute ~350 authenticated GET requests per hour on behalf of that user from
your server's IP address. There are 24 hours in a day. That's 8,400
authenticated GET requests you can make on their behalf per day, in which
you're fetching timelines for them, user profile metadata, and so on.

If there are specific actions you can't perform for a certain user within
350 requests in a given hour, you queue the rest of the activity and ask the
user to wait until you can process the data for them.

Interested to know where a whitelisting requirement fits in with your use
case.

@episod  - Taylor Singletary - Twitter Developer
Advocate


On Thu, Mar 17, 2011 at 3:22 PM, hank williams  wrote:

> Ryan,
>
> I have asked this a few times, (every time you mention using site
> streams) and I realize everyone at twitter is really busy, but it
> would be really helpful to know whether it is possible to write
> twitter web based apps right now given that there is no whitelisting,
> and site streams seems to be in closed beta. It would seem without
> site streams, creating webapps that use twitter would be impossible.
> If there is some workaround that I don't know about, please let me
> know.
>
> Thanks,
> Hank
>
> On Thu, Mar 17, 2011 at 6:09 PM, Ryan Sarver  wrote:
> > Ed, I'm not sure what you mean by: "You need to get *all* your users to
> > *explicitly* authorize the application's *exact* usage of their data!"
> > Of course! that is exactly what we are saying and I'm not sure if you're
> > really saying you shouldn't get the user's authorization as that doesn't
> > make sense.
> > I don't expect everyone to be able to use User Streams or Site Streams,
> but
> > that is why the REST API exists.
> >
> > --
> > Ryan Sarver
> > @rsarver
> >
> >
> > On Wed, Mar 16, 2011 at 8:52 PM, M. Edward (Ed) Borasky
> >  wrote:
> >>
> >> On Wed, 16 Mar 2011 09:10:13 -0700 (PDT), "Ryan Sarver (@rsarver)"
> >>  wrote:
> >>>
> >>> Also as we stated before, you can use User Streams or Site Streams and
> >>> get more data by getting more users to authorize your application.
> >>
> >> Ryan, it's not as simple as "getting more users to authorize your
> >> application." You need to get *all* your users to *explicitly* authorize
> the
> >> application's *exact* usage of their data! Users tend not to "read the
> fine
> >> print". I'd hate to see some data collection / analytics application
> make
> >> some assumptions based on the implicit openness of the tweet stream and
> then
> >> get nailed by a bunch of angry users. Angry users tend to write to their
> >> Congressmen and Senators. ;-)
> >>
> >> Managing a *single* user's User Streams feed is a relatively
> >> straightforward coding task - I've got a smallish Perl script that can
> do it
> >> for my own account. Managing multiple users' Site Streams is a much more
> >> complex endeavor, and to use that mechanism for a data collection /
> >> analytics application is ludicrous IMHO. Somehow, the notion of "the
> right
> >> tool for the job" seems to have been ignored. ;-)
> >>
> >> --
> >> http://twitter.com/znmeb http://borasky-research.net
> >>
> >> "A mathematician is a device for turning coffee into theorems." -- Paul
> >> Erdős
> >>
> >> --
> >> 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
> >
>
> --
> 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

Re: [twitter-dev] Re: Requesting increased access levels for Streaming API

[hank williams]

Ryan,

I have asked this a few times, (every time you mention using site
streams) and I realize everyone at twitter is really busy, but it
would be really helpful to know whether it is possible to write
twitter web based apps right now given that there is no whitelisting,
and site streams seems to be in closed beta. It would seem without
site streams, creating webapps that use twitter would be impossible.
If there is some workaround that I don't know about, please let me
know.

Thanks,
Hank

On Thu, Mar 17, 2011 at 6:09 PM, Ryan Sarver  wrote:
> Ed, I'm not sure what you mean by: "You need to get *all* your users to
> *explicitly* authorize the application's *exact* usage of their data!"
> Of course! that is exactly what we are saying and I'm not sure if you're
> really saying you shouldn't get the user's authorization as that doesn't
> make sense.
> I don't expect everyone to be able to use User Streams or Site Streams, but
> that is why the REST API exists.
>
> --
> Ryan Sarver
> @rsarver
>
>
> On Wed, Mar 16, 2011 at 8:52 PM, M. Edward (Ed) Borasky
>  wrote:
>>
>> On Wed, 16 Mar 2011 09:10:13 -0700 (PDT), "Ryan Sarver (@rsarver)"
>>  wrote:
>>>
>>> Also as we stated before, you can use User Streams or Site Streams and
>>> get more data by getting more users to authorize your application.
>>
>> Ryan, it's not as simple as "getting more users to authorize your
>> application." You need to get *all* your users to *explicitly* authorize the
>> application's *exact* usage of their data! Users tend not to "read the fine
>> print". I'd hate to see some data collection / analytics application make
>> some assumptions based on the implicit openness of the tweet stream and then
>> get nailed by a bunch of angry users. Angry users tend to write to their
>> Congressmen and Senators. ;-)
>>
>> Managing a *single* user's User Streams feed is a relatively
>> straightforward coding task - I've got a smallish Perl script that can do it
>> for my own account. Managing multiple users' Site Streams is a much more
>> complex endeavor, and to use that mechanism for a data collection /
>> analytics application is ludicrous IMHO. Somehow, the notion of "the right
>> tool for the job" seems to have been ignored. ;-)
>>
>> --
>> http://twitter.com/znmeb http://borasky-research.net
>>
>> "A mathematician is a device for turning coffee into theorems." -- Paul
>> Erdős
>>
>> --
>> 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
>

-- 
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-dev] Re: consistency and ecosystem opportunities

[O O O]

All of this would have been much easier if they would have stayed with my 
start up of Twitter

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

Re: [twitter-dev] Re: Requesting increased access levels for Streaming API

[Ryan Sarver]

Ed, I'm not sure what you mean by: "You need to get *all* your users to
*explicitly* authorize the application's *exact* usage of their data!"

Of course! that is exactly what we are saying and I'm not sure if you're
really saying you shouldn't get the user's authorization as that doesn't
make sense.

I don't expect everyone to be able to use User Streams or Site Streams, but
that is why the REST API exists.

--
Ryan Sarver
@rsarver 



On Wed, Mar 16, 2011 at 8:52 PM, M. Edward (Ed) Borasky <
zn...@borasky-research.net> wrote:

> On Wed, 16 Mar 2011 09:10:13 -0700 (PDT), "Ryan Sarver (@rsarver)" <
> ryan.sar...@gmail.com> wrote:
>
>>
>> Also as we stated before, you can use User Streams or Site Streams and
>> get more data by getting more users to authorize your application.
>>
>
> Ryan, it's not as simple as "getting more users to authorize your
> application." You need to get *all* your users to *explicitly* authorize the
> application's *exact* usage of their data! Users tend not to "read the fine
> print". I'd hate to see some data collection / analytics application make
> some assumptions based on the implicit openness of the tweet stream and then
> get nailed by a bunch of angry users. Angry users tend to write to their
> Congressmen and Senators. ;-)
>
> Managing a *single* user's User Streams feed is a relatively
> straightforward coding task - I've got a smallish Perl script that can do it
> for my own account. Managing multiple users' Site Streams is a much more
> complex endeavor, and to use that mechanism for a data collection /
> analytics application is ludicrous IMHO. Somehow, the notion of "the right
> tool for the job" seems to have been ignored. ;-)
>
> --
> http://twitter.com/znmeb http://borasky-research.net
>
> "A mathematician is a device for turning coffee into theorems." -- Paul
> Erdős
>
> --
> 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

Re: [twitter-dev] Re: consistency and ecosystem opportunities

[Ryan Sarver]

Dewald, sorry if this isn't clear. The intent is to allow developers to
still post to other 3rd party networks like Facebook, Identica, LinkedIn,
etc. What we don't want to allow is for a client to use our content to build
their own competing status service and by sending content to services that
the user did not intend to send them to.

Users trust us with their content and we want them to have an idea of where
the content goes and how it is going to be used.

Hope that helps clarify.

Ryan



--
Ryan Sarver
@rsarver 



On Mon, Mar 14, 2011 at 8:43 AM, Dewald Pretorius  wrote:

> Taylor,
>
> Would you mind taking a stab at clarifying Section 5.E of the new TOS,
> which reads, "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."
>
> It appears to say that a Client is not allowed to offer its users the
> ability to create status updates on other services (StatusNet,
> Facebook, etc.). Had it not been for the "or other data collected from
> end users" I would have interpreted it that one cannot use any Twitter
> Content (user data and tweets obtained via the Twitter API) and feed
> that Twitter Data into other and/or competing social network
> platforms. But, "or other data collected from end users" seems to
> suggest that one cannot so much as offer any support for any other and/
> or competing social network platform. Meaning, if you have a Client,
> you can support Twitter OR Everything Else, not both.
>
>
> On Mar 14, 11:12 am, Taylor Singletary 
> wrote:
> > Hi Adam,
> >
> > Thanks for your comments as always. I can help clarify a bit around how
> > clients will be held to higher standards.
> >
> > Criteria we may examine include: is the application in tune with the
> spirit
> > of the developer guidelines? Does the application refrain from storing
> > username & password if it's using xAuth? Are tweets displayed with the
> > proper attribution? Are the actions presented for the tweet appropriate
> in
> > respect to it being a tweet? Does the application frame portions of our
> > mobile site? Does it store non-public user data in a public way? Does the
> > application provide a privacy policy? Is the client application paying
> for
> > installation on mobile carriers?
> >
> > The new terms also offer some examples that are reasonably specific:
> >
> >
> >
> >
> >
> > >> A. 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.
> >
> > >  B. You may not pay, or offer to pay, third parties for distribution of
> > >> your Client. This includes offering compensation for downloads (other
> than
> > >> transactional fees), pre-installations, or other mechanisms of traffic
> > >> acquisition.
> >
> > >  C. Your Client cannot frame or otherwise reproduce significant
> portions of
> > >> the Twitter service. You should display Twitter Content from the
> Twitter
> > >> API.
> >
> > > D. Do not store non-public user profile data or content.
> >
> > > E. 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
> >
> > Using a Twitter client is like using an extension of Twitter, and though
> the
> > user interfaces may change we want to ensure that the user experience is
> > consistent, whether it's consistency in the actions a user can perform
> with
> > a Tweet, the way their private information is treated, or how slowly,
> > quickly, and with what tact advertising flows or does not flow through
> the
> > network.
> >
> > Taylor
> >
> > On Sun, Mar 13, 2011 at 9:55 PM, Adam Green <140...@gmail.com> wrote:
> > > Yes! Transparency!  That is what we are really craving. That is the
> subtext
> > > for every developer responding to this thread. What we all want is
> > > transparency about being shut down. Why does Twitter "revoke literally
> > > hundreds of API tokens / apps a week" as Ryan said? Is it for something
> > > obvious, like pumping out thousand of spam tweets or abusive follows,
> or is
> > > it for something innocent, like not putting the right text on a tweet
> > > button? I have never seen a description of an app that was blocked,
> except
> > > for a few loons like Edward H. What if you told us about apps that get
> > > blocked as examples, and explain what they did wrong? You don't even
> have to
> > > identify them by name. Just explain exactly what type of transgressions
> are
> > > causing rejection. That could calm people down.
> >
> > > Who doesn't meet the "high bar" and why? I know "high bar" has a lot of
> > > meaning to you Twitter guys, since you all use the same term (a real
> example
> > > of groupthink, BTW), but it means nothing

Re: [twitter-dev] Please hire a developer relations manager

[Ryan Sarver]

Adam,

I appreciate the email and think you raise some great points. It's all stuff
that we aspire to be able to do and things that I think foster great
developer ecosystems. We are currently growing the developer advocate team
to get poor Matt and Taylor some help (
https://twitter.com/job.html?jvi=o5DxVfwU,Job).

Please send along any recommendations of people you think would be a great
fit for the role. We have a few more people starting in two months which I
think will make a big difference.

Ryan

--
Ryan Sarver
@rsarver 



On Mon, Mar 14, 2011 at 6:44 AM, Adam Green <140...@gmail.com> wrote:

> First of all, I honestly believe that Twitter HQ values developers and
> appreciates their contribution. That is why I decided to devote myself
> to this area a couple of years ago. I was amazed that when a dev
> reported a problem the engineer responsible replied here and tried to
> solve it. That is better than any big product I know of today. That is
> why you have so many developers putting in all this work.
>
> I also believe that the last few announcements from Ryan and others
> have been the worst examples of third party developer management I
> have seen in 30 years in this business. I can see what Ryan wanted to
> accomplish in his latest message. He wanted to provide guidance. He
> ended up telling us that Twitter no longer wanted anyone to build
> clients, didn't explain clearly what a "client" meant to him, and
> pointed out that hundreds of apps that fail to meet his undefined
> "high bar" were cut off every week. Not good. Sorry, Ryan. You are
> right. You are not good at communicating with third party developers.
> At least not in written form. You look like a very cool guy with a lot
> of personal charm. Maybe it works better in person. You should spend
> some time talking directly to developers in small groups. It might
> help you develop some canned responses that work.
>
> Here is a simple way this could have been prevented. If you had a
> developer relations person with experience and skills in dealing with
> third party developers, who have completely different motivations from
> in-house coders, he or she could have quietly passed around a draft of
> what you wanted to say. This would have gotten very strong negative
> reactions. You would have been able to reformulate it to strip out the
> implied threats and turn it into a positive roadmap. It could have
> been framed as "Here are some areas we promise to leave open for
> developers. If you work here, we will give you all kinds of extra
> support and promotion."
>
> Here is another simple way this could have been prevented. Create an
> advisory board of developers. Rotate people through it every 6-12
> months. Let them vet announcements in advance. Let them respond to the
> questions. It works in every other company I have worked with.
>
> Here is what could be done instead of these repeated bombs you keep
> dropping on the community. Give people a present. Announce that you
> will use some of your precious ad space to promote third party apps,
> and not just the ones with millions of dollars of VC who happen to
> work in your building. Find new ways to rev share with developers.
> Offer all expense paid trips to select developers to visit your office
> for a day to hang out. HOLD A DEVELOPERS CONFERENCE.
>
> There are many other things a good developer relations person could
> do. Talk to Guy. That is how he started for Apple.
>
> One last thing. Give this developer relations person a seat at the
> table when big decisions are made. I can read lots of signals, like
> this "high bar" nonsense, that there are negative attitudes inside
> Twitter towards developers. They are a pain in the ass. Yes. But they
> do hundreds of millions of dollars in development and promotion for
> you for free. Hire someone good for $100K+. Give them a million dollar
> budget to really take care of developers and run conferences and get
> togethers around the world. It will pay off many times over.
>
> --
> 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

Re: [twitter-dev] Hoping to clear my confusion about Twitter's announcement

[Ryan Sarver]

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

--
Ryan Sarver
@rsarver 



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

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 th

Re: [twitter-dev] Re: consistency and ecosystem opportunities

[Ryan Sarver]

Steve, thanks for the email. Some inline responses below...

--
Ryan Sarver
@rsarver 



On Wed, Mar 16, 2011 at 8:24 PM, Steve Eley  wrote:

> On Mar 11, 4:18 pm, Ryan Sarver  wrote:
> >
> > With more people joining Twitter and accessing the service in multiple
> ways,
> > a consistent user experience is more crucial than ever.  As we talked
> about
> > last April, this was our motivation for buying Tweetie and developing our
> > own official iPhone app.  It is the reason why we have developed official
> > apps for the Mac, iPad, Android and Windows Phone, and worked with RIM on
> > their Twitter for Blackberry app. As a result, the top five ways that
> people
> > access Twitter are official Twitter apps.
>
> Something doesn't sound right here.  The official reasoning has some
> contradictions in it:
>
> * You're telling us that Twitter's own apps are topping the market,
> and that an overwhelming majority of people are engaging with Twitter
> using your own tools.
>

90% logging in once a month is one measurement. We can't currently measure
tweet views which would be the best measurement of consumption. I wouldn't
say that Twitter is the overwhelming majority of the way people consume
twitter, but it's the majority and trending in that favor.


>
> * In the same message, you say that people are confused about how to
> engage with Twitter. You blame non-standard third party interfaces --
> but if they're just a small minority of user contact points with
> Twitter, wouldn't the impact be fairly low-level and mitigated by the
> superior first-party experience?
>

While Twitter owned and operated clients are the majority, but not the
overwhelming majority, there is still a lot of confusion for mainstream
users across the fractured experiences.


>
> * In that message and in subsequent followups, you tell us that client
> applications will be "held to a higher bar."  This seems to imply that
> the standards for acceptance or rejection are qualitative; however,
> the revised Terms of Service imply that they are objective.  Which is
> it?  Is it "If you implement X, we'll cut you off" -- or is it "We
> encourage you not to implement X, but if you do, we'll decide whether
> you're any good at it?"
>

Clearly people have taken this to mean something I didn't intend. When I
said "higher bar" I meant that relative to the previous TOS. I don't mean it
in an arbitrary, qualitative way. While we don't recommend it as a business,
we aren't going to be turning off clients as long as they stay within the
articulated TOS. Obviously there are a number of smaller international
markets, use cases and devices that our clients don't address and these are
great for niche clients.


>
> Fundamentally, here's what doesn't smell right to me: if the superior
> quality of Twitter's first-party platform is winning in the
> marketplace, as you say it is, _why bother with this?_  The perceived
> threat to the user experience doesn't make sense.  New users who don't
> understand Twitter yet aren't going to pick up third-party clients;
> they're going to follow the brand name.  They'll go to Twitter.com, or
> buy a book, or ask their friends.  (If the books or friends are
> confused, new API terms won't help.)
>

Why bother? Because on a weekly, if not daily basis, we get asked by
developers, entrepreneurs, angels and VCs for "more guidance and
transparency". If we know we are going to invest heavily in a space and feel
that a consistent user experience is key to onboarding more new users and
optimizing the network effects, then we need to communicate that to
everyone. The email was meant to be blunt, and we know it's not a message
that everyone wants to hear. Some people have taken acception to the
bluntness of the language, but I think brutal honesty is better than dancing
around the topic with niceties.


>
> GOOD third-party clients don't compete with Twitter for new user
> share.  They pick up the power users who've used Twitter for a while
> and want to use it more, or who have particular needs or tastes, or
> who _like_ crazy non-standard designs.  Shutting them down won't help
> new users, and it won't enable current users to do things better.
> It'll just turn power users into non-power users, or in some cases
> into non-users.  The most valuable users don't settle for 'good
> enough.'  If Twitter doesn't let them do things their own way, they'll
> find a platform that does, or make one.
>

I totally agree, hence why I called out applications focused on the
enterprise market and marketers like HootSuite, CoTweet and Seesmic. And
again, to be really clear, we aren't shutting down any clients, even ones
focused on the mainstream consumer experience. However, if you're going to
build a "client", we would like to see more of them like CoTweet that focus
on a specific audience with specific needs not addressed by the core Twitter
clients.


>
> BAD third-party clients don't compete with Twitter at all.  Th

[twitter-dev] Invalid / suspended application

[meghraj]

I am using the Abraham's code downloaded from GIthub for simple
application which authorizes and post a tweet on user's wall which
authorize it.

I simply put the

consumer key
consumer secret
and callbackurl

which I got after registering this application
in the config.php file.

It worked fine for 1 day but now I am getting this error in
application

"Could not connect to Twitter. Refresh the page or try again later."

and in twurl console (suppose for account/verify_credentials)




(request)


opening connection to api.local.twitter.com...
opened
<- "GET /1/account/verify_credentials.xml HTTP/1.1
Accept: */*
Connection: close
User-Agent: OAuth gem v0.3.4.1
Authorization: OAuth oauth_nonce=
\"E8kvCmeV6sVMt0I8a2cSzc5wSfx7Io3VxXl69JiY\", oauth_signature_method=
\"HMAC-SHA1\", oauth_timestamp=\"1300390460\", oauth_consumer_key=
\"1i22KFwI3N6L3OcYtQEg\", oauth_token=\"265968250-
O7WgA41oR4IPrk05jcYju88Y26kNAZAlRhQUJKCA\", oauth_signature=
\"ue89%2B5vF%2FLxZngI6T%2B6%2FMedfa8M%3D\", oauth_version=\"1.0\"
Host: api.local.twitter.com:9000








(response)

Response Headers
Expires: Thu, 17 Mar 2011 20:04:20 GMT
Connection: close
Content-Type: application/xml; charset=utf-8
Www-Authenticate: OAuth realm="http://api.local.twitter.com:9000";
Server: hi
Date: Thu, 17 Mar 2011 19:34:20 GMT
Content-Length: 158
Set-Cookie: k=10.59.200.50.1300390460906353; path=/; expires=Thu, 24-
Mar-11 19:34:20 GMT; domain=.twitter.com, guest_id=130039046090950671;
path=/; expires=Sat, 16 Apr 2011 19:34:20 GMT,
_twitter_sess=BAh7BiIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6Rmxhc2g6OkZsYXNo
%250ASGFzaHsABjoKQHVzZWR7AA%253D
%253D--1164b91ac812d853b877e93ddb612b7471bebc74; domain=.twitter.com;
path=/; HttpOnly
Vary: Accept-Encoding
Cache-Control: no-cache, max-age=1800
Status: 401 Unauthorized
Response Body



  /1/account/verify_credentials.xml
  Invalid / suspended application





and also when I click on "My access Token" from application settings
page, then I get only one line on top left page as follows

/apps/796740/my_token Invalid / suspended application


please give me any solution for this, I read a similar problem in this
group but there was no reply for that problem(post)

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

Re: [twitter-dev] Twitter Auth: iPhone + Web

[Taylor Singletary]

Hi there,

In most cases for native clients on iPhone, Android, Blackberry, and so on,
developers prefer to use xAuth  for
token negotiation. To use xAuth, you need permission from Twitter which you
can inquire for by emailing a...@twitter.com with verbose details about your
application(s), screen shots of it in action, and so on.

If your service already supports Twitter outside of the mobile app space,
and you already provide an auth mechanism for your service that is not
Twitter (for example, a username/password combo) then you might want to
require your users to log in that way into your application, then send the
appropriate access token you already have for the user downstream to the
client application. Likewise for upstream -- if you need users to initiate a
relationship between your service and Twitter on the mobile device itself,
you'd make that negotiation happen on the device, then send the access token
upstream to your servers for use in the core service.

Another approach that can ultimately offer you a greater level of
flexibility (at the cost of some greater maintenance costs) is to use
separate API keys for each platform your application is featured on (iPhone,
Android, web, etc.), re-negotiating Twitter auth in each platform as an
action the user is deliberately taking in the context of that device. You'd
then send access tokens upstream to your servers and maintain a mapping of
the user's various Twitter access tokens in respect to the device that the
use.

Finally, we always prefer you to use the standard OAuth flow as opposed to
xAuth. You can use dynamic callback URLs to target application-specific URIs
and simplify the web-based OAuth dance greatly. This approach frees you from
the stress & responsibility of directly collecting a username and password.

Taylor

@episod  - Taylor Singletary - Twitter Developer
Advocate


On Thu, Mar 17, 2011 at 11:47 AM, jdjaramillo  wrote:

> Hello,
>
> we have a website where the users can currently connect their Twitter
> accounts and update their tweets automatically by interacting with our
> site. Now we are building an iPhone, Android and Blackberry app which
> should allow the user to connect his account to the same Twitter APP.
>
> We currently have the app set as "web" with a regular callback URL. Is
> it possible to authenticate on the mobile apps using the same app but
> without having the user open a browser window? How can we do this?
>
> thanks,
>
> --
> 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

[twitter-dev] Twitter Auth: iPhone + Web

[jdjaramillo]

Hello,

we have a website where the users can currently connect their Twitter
accounts and update their tweets automatically by interacting with our
site. Now we are building an iPhone, Android and Blackberry app which
should allow the user to connect his account to the same Twitter APP.

We currently have the app set as "web" with a regular callback URL. Is
it possible to authenticate on the mobile apps using the same app but
without having the user open a browser window? How can we do this?

thanks,

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

Re: [twitter-dev] Retweet chain

[Tom van der Woerdt]

No, it's not. You can, however, analyze who gets the retweet in the 
timeline and build the chain that way. Of course, this won't work if you 
have a huge amount of retweets. Also, it's not 100% accurate.


Tom


On 3/17/11 6:47 PM, Karthik Murugan wrote:

Let us assume:

C follows B. B follows A

A sends a tweet and B retweets it.

C gets the retweet on his timeline and retweets it again.


I'm connected to UserStream of A and I receive both the retweets. But 
not sure how to find the retweet chain


How can we know that C retweeted it via B? Is it exposed in any API 
methods?



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

[twitter-dev] Retweet chain

[Karthik Murugan]

Let us assume:

C follows B. B follows A

A sends a tweet and B retweets it.

C gets the retweet on his timeline and retweets it again.


I'm connected to UserStream of A and I receive both the retweets. But not 
sure how to find the retweet chain

How can we know that C retweeted it via B? Is it exposed in any API methods?


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

Re: [twitter-dev] Invalid username/password

[Scott Wilcox]

That code will no longer work, basic authentication is no longer support for 
the Twitter API. You will need to use OAuth to do so.

You can find some examples of using the twitter-async library written by Jaisen 
Mathai at:

https://github.com/dordotky/oauth-twitter-examples

Hope this helps.

Scott.

On 17 Mar 2011, at 16:07, steiljesoc wrote:

> I'm using the my_twitter PHP library from twitter website but every
> time I try to post a status I get an invalid username/password. Here's
> the code that's making the curl call.
> 
> Any ideas?
> 
> $ch = curl_init();
>   curl_setopt($ch, CURLOPT_URL, $url);
>   curl_setopt($ch, CURLOPT_HTTPAUTH, 
> CURLAUTH_ANY);
>   curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
>   curl_setopt($ch, CURLOPT_USERPWD, 
> $this->Username.':'.$this-
>> Password);
>   curl_setopt($ch, CURLOPT_GET, true);
>   curl_exec($ch);

-- 
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-dev] Invalid username/password

[steiljesoc]

I'm using the my_twitter PHP library from twitter website but every
time I try to post a status I get an invalid username/password. Here's
the code that's making the curl call.

Any ideas?

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_HTTPAUTH, 
CURLAUTH_ANY);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_USERPWD, 
$this->Username.':'.$this-
>Password);
curl_setopt($ch, CURLOPT_GET, true);
curl_exec($ch);

-- 
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-dev] Use search api or site stream for short duration repeated query searches?

[Joe Bowman]

Hello,

I'm working on the design for a realtime like social search for a personal 
project I have at www.unscatter.com. I'm building on various apis like Bing, 
Blekko, Facebook, Twitter and more. 

One of the next items I want to implement is the ability to do a search and 
get constant updates from Facebook and Twitter. My instinct is to use the 
search api, rather than streams, because the queries won't be long lasting 
ones. The 2 implementation choices I see are

Both:
User submits a query for say "bird"
I'll check first to makes sure there isn't already a query running for 
"bird", if there is I'll poll the backend for it.
If there isn't a query running already, I'll initiate one by dropping "bird" 
in the datastore as an active query.
Then I'll have a secondary program which will do one of the following for 
Twitter specifically

Search api:
Will poll the api for "bird" for updates newer than the latest result 
already cached.
If it gets a result it will drop it in the datastore so that the front end 
can pick it up and deliver it to the consumer.

Stream:
Shut down any active stream
Start a new stream with "bird" added to the track list
Parse results as they come in, searching for "bird" and adding them to the 
query queue if it exists.

The engine running the queries will work off of a last request timestamp 
supplied by front ends to determine if the query is still active.
So for the 2 solutions

Search api:
Stop polling

Stream:
Shut the stream down and remove "bird" from the track list.

It seems to me that as these are short term queries that the search api is 
the way to go. I actually had this working just like that at one point 
before I did a rewrite of the application


note: I use the term datastore, but I'm not using appengine. It's a python 
tornado/mongodb architecture server side. 

Just want to validate that using the search api is appropriate here. 

I intend to add features later that will consume the stream using site 
stream for accounts, but this doesn't seem to be the appropriate place to 
start using it with the fact I'd be stopping and starting the stream to 
manage track keywords often.

-- 
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-dev] Change share icon background

[sarity]

Hi,
I would like to know how if I can change the background of share
twitter button and put different image as background instead of it.

thanks

-- 
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-dev] auto-link no longer works on urls ending in -

[Ethan]

I am publishing urls as part of status updates that sometimes end with
a hyphen.  Up until recently, these have been auto-linked correctly by
twitter.  Recently this changed, and the hyphens at the end of the
link are not included in the links I post to the API.  For example,
http://aweber.com/b/os7- would have linked correctly before, but now
links to http://aweber.com/b/os7 instead.  Is this a bug or a
permanent change at Twitter?

Is there a way to explicitly define the links that get picked up?  I
see that complete urls and start / end points are included in the
entities: urls section of a tweet, but it is not clear if I am able to
_submit_ the entities section for my own posts.

Any help is appreciated.

Thanks,
Ethan

-- 
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-dev] search API and until parameter

[Yusuke Yamamoto]

Hi,

What is the timezone used by the search API?

The first tweet hit with q=#todoke&until=2011-03-16 is id=48156449427300352 
which is created at "Wed Mar 16 22:59:26 + 2011".
But there are tweets posted later on that day that should hit with the query 
such as id=48171154753601536 which is created at "Wed Mar 16 23:57:52 + 
2011".

Best,
-- 
Yusuke Yamamoto
yus...@mac.com

this email is: [x] bloggable/tweetable [ ] private
follow me on : http://twitter.com/yusukeyamamoto
subscribe me at : http://samuraism.jp/

-- 
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-dev] Missing step in oauth implementation

[Randomness]

I have gone through the process of implementing oauth from scratch on
my website, but am unclear about one step in the process.

Acquiring a request token is not a problem and I am getting an
oauth_token and oauth_token_secret fine, no problems there. But after
this I am sending the user to Twitter to authorize after which Twitter
will redirect the user to my website, and I have lost control over the
user. Testing it on my own pc works fine and I can get read the
verifier from the url on the screen. Combined with the previously
acquird tokens I than receive back the screen_name and user_id + plus
the required token and secret.

The problem is that I do this in two steps, while reading an url from
my screen. Obviously when a user somehwhere else does this I cannot
read the verifier from the screen and continue the process.

I am missing something with the oauth_callback and how to use this. I
should get the oauth_verifier back in the first script which then
should continue with acquiring and storing the tokens, and it should
not be a two step process. How do I solve this?

-- 
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-dev] The api console search user is not working i have key in the 'q' in parameter.

[Jimmy Au]

The api console search user is not working i have key in the 'q' in
parameter. Why?
https://dev.twitter.com/console/recall?client_application_id=777667&content_type=json&method=GET¶m-keys%5B%5D=q¶m-vals%5B%5D=wedadasdsa&path=users%2Fsearch&version=1


{
  "request": "\/1\/users\/search.json",
  "error": "Client must provide a 'q' parameter with a value."
}

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

Re: [twitter-dev] Questions of new ToS

[Taylor Singletary]

Hi Jack,

Twitter has moved on to using the #newtwitter-style bird for all branding
materials, and the terms of service now indicate this requirement
externally. No more "t"s. We know it will take time for applications to
adjust.

As for the second requirement, you wouldn't be allowed to list a
representation of a specific Twitter user's followers in your application
without a visual indication showing that these following relationships
happened on Twitter. This might be as simple as using a heading above the
list that says "@jack's followers on Twitter" or "Twitter Followers"
or "[image:
t_mini-a.png] Followers" -- this is a good idea for any kind of Twitter data
being used in your application -- especially if you intermingle Twitter
data/objects/actions with data from other services.

Taylor

On Thu, Mar 17, 2011 at 4:09 AM, Chen Jack S Y  wrote:

> Hey,
>
> Anyone from twitter development team can explain a little bit of the
> content in new ToS:
>
> III. Twitter Functionality in your Service
> 3. Twitter Identity
> *Once an end user has authenticated via Connect with Twitter, you must
> clearly display the end user's Twitter identity. Twitter identity includes
> visible display of the end user's avatar, Twitter user name, and the Twitter
> "bird" mark. Displays of the end user's followers on the your Service must
> clearly show that the relationship is associated with the Twitter service.
>
> *Q1: Have to display the 'bird' mark? Can't be the blue login with 't' ?
> Q2: Any example of showing followers relationship is associated with the
> Twitter service? Because don't know exactly how you mean by this.
>
> Jack*
> *
>
> --
> 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

[twitter-dev] New form of follow spam

[Adam Green]

Is anyone else seeing this?

I'm getting a very odd type of follower. These are accounts that have
0 tweets, and yet are following thousands of people and being followed
back by large numbers. I understand follow spam when you have some
message to spread, but this is confusing. Is the goal to create
accounts with followers that can be sold? What can be the purpose?
Should Twitter add this to their spam follow detection? These accounts
have more than the 2,000 friends limit. Seem's like this type of
following with no tweets should be blocked, because it must "confuse"
users, and that is something Twitter doesn't want.

Also these accounts seem more human. They have pictures that are not
partially clothed "models", and they don't have the spam screen name
formula of a female first name followed by 4 digits. Could these
accounts be for actual humans who just want to read certain twitter
accounts, so they use following as a way of creating a reading list?

-- 
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-dev] Questions of new ToS

[Chen Jack S Y]

Hey,

Anyone from twitter development team can explain a little bit of the content
in new ToS:

III. Twitter Functionality in your Service
3. Twitter Identity
*Once an end user has authenticated via Connect with Twitter, you must
clearly display the end user's Twitter identity. Twitter identity includes
visible display of the end user's avatar, Twitter user name, and the Twitter
"bird" mark. Displays of the end user's followers on the your Service must
clearly show that the relationship is associated with the Twitter service.

*Q1: Have to display the 'bird' mark? Can't be the blue login with 't' ?
Q2: Any example of showing followers relationship is associated with the
Twitter service? Because don't know exactly how you mean by this.

Jack*
*

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