date:20090609

The summary is
I propose that the follow limits be dependent on whether a user is following
an individual or not. It should only count against me if the user is not
following me already and I try to follow them.  :-)
Jesse

On Tue, Jun 9, 2009 at 11:35 PM, Abraham Williams <4bra...@gmail.com> wrote:

> Can someone tweet a summery to @abraham? :-P
> Thanks,
> Abraham
>
>
> On Wed, Jun 10, 2009 at 00:28, Jesse Stay  wrote:
>
>> Let's discuss the follow limits.  I feel, as developer of a tool that
>> allows people to auto-follow, I have a bit of insight into this.  While
>> there are many, many legitimate users that auto-follow others, and have good
>> reason to do so, some are using it as a way to game the system, build
>> followers quickly, break the Twitter TOS, and reduce the meaning of follower
>> numbers for many other users just using the service legitimately.  I see
>> this daily, amongst a few of my own users, and while, due to our privacy
>> policy I can't share who they are, I do have some suggestions that would
>> make the API follow limits make a little more sense.  Maybe you guys can
>> provide more insight.
>>
>> -Currently the follow per day limit is 1,000 follows per user per day.
>>  There is no limit on the number of unfollows a user can do per day (that I
>> know of), and it appears as though there is also a limit of around 10% for
>> the number of users a person can follow more than follow them back.  The
>> users taking advantage of Twitter have figured this out.  So here's what
>> they do:
>>
>> A "gamer"'s typical activity is that they will follow as many people as
>> they can - most up to the 1,000 limit they're allowed per day, until they
>> hit the ratio of 10%.  The higher the follower base they gain, the longer
>> they're able to do this.  They then hope a good portion of those 1,000
>> people follow back.  Those that don't use tools like mine (which weren't
>> intended to be used this way) to unfollow everyone who is not following them
>> back.  This is often much greater than 1,000 for the users that are really
>> good at it.  The process then starts over.  They'll use tools like
>> Hummingbird (Google it) and Twollo to find people and automatically go out
>> and follow them.  This is why I refuse to create auto-follow filters to find
>> new people on my service. It's way too spammy if you ask me.
>>
>> Why do they do this?  2 reasons: 1, "supposedly" having more followers
>> means more visits and clicks in whatever you're trying to promote. (I don't
>> believe this)  and 2, many of these people also have auto-DM set up to send
>> links and messages to each person that follows them back.  Back when I
>> offered this service (we disabled it for this exact reason) people told me
>> they were seeing significant clicks on the links they would send to people
>> via DM after they followed them.  Therefore, more follows==more clicks==more
>> revenue. I don't blame them if that's what they're really seeing.
>>
>> So for this reason I think having limits in place is a *good* thing.  I
>> don't think the follow limit is in place due to traffic reasons, since there
>> are many more calls that cause more traffic on the API and there is no limit
>> to unfollows, so I really think Twitter is doing this for the purpose of
>> reducing spam and "gaming" of Twitter.  This is a good thing.
>>
>> However, I think Twitter may be approaching the limits the wrong way.
>>  Here's what I think would be more effective, and beneficial for the
>> legitimate users that want to follow back and at the same time not allow
>> those who want to game the system to use the methods I described.  Twitter
>> needs to impose limits based on whether the individual is following the user
>> back or not.
>>
>> For instance, if I follow @dacort and he is following me back, that
>> shouldn't count against me as a hit against my follow limit.  However, if I
>> try to follow @dacort and he is not following me back, it should count
>> against me as a hit against my limit.  With this, users could easily
>> auto-follow back if they choose to, and it would still be difficult for the
>> users trying to game the system and spam Twitter.  In fact, you could
>> significantly *reduce* the limit this way and make it virtually impossible
>> for these users to use Twitter in that manner.  If you were to look at the
>> relationship between the users when counting against limits, you could
>> probably reduce the follow/day limit all the way to around 200 per day
>> instead of 1,000 per day.  I don't see any reason for the 10%
>> follow/follower ratio with a low limit such as that.
>>
>> However, as stands, the more followers you get, if you are using Twitter
>> legitimately, you have no way to extend the courtesy back if you choose to
>> do so, since after a certain point you will be following many more than
>> 1,000 users per day.  And even if you aren't, it will take an extremely long
>> time for many individuals to finally catch up to f

[twitter-dev] Re: Follow Limits - a Discussion

2009-06-09 Thread Abraham Williams

Can someone tweet a summery to @abraham? :-P
Thanks,
Abraham

On Wed, Jun 10, 2009 at 00:28, Jesse Stay  wrote:

> Let's discuss the follow limits.  I feel, as developer of a tool that
> allows people to auto-follow, I have a bit of insight into this.  While
> there are many, many legitimate users that auto-follow others, and have good
> reason to do so, some are using it as a way to game the system, build
> followers quickly, break the Twitter TOS, and reduce the meaning of follower
> numbers for many other users just using the service legitimately.  I see
> this daily, amongst a few of my own users, and while, due to our privacy
> policy I can't share who they are, I do have some suggestions that would
> make the API follow limits make a little more sense.  Maybe you guys can
> provide more insight.
>
> -Currently the follow per day limit is 1,000 follows per user per day.
>  There is no limit on the number of unfollows a user can do per day (that I
> know of), and it appears as though there is also a limit of around 10% for
> the number of users a person can follow more than follow them back.  The
> users taking advantage of Twitter have figured this out.  So here's what
> they do:
>
> A "gamer"'s typical activity is that they will follow as many people as
> they can - most up to the 1,000 limit they're allowed per day, until they
> hit the ratio of 10%.  The higher the follower base they gain, the longer
> they're able to do this.  They then hope a good portion of those 1,000
> people follow back.  Those that don't use tools like mine (which weren't
> intended to be used this way) to unfollow everyone who is not following them
> back.  This is often much greater than 1,000 for the users that are really
> good at it.  The process then starts over.  They'll use tools like
> Hummingbird (Google it) and Twollo to find people and automatically go out
> and follow them.  This is why I refuse to create auto-follow filters to find
> new people on my service. It's way too spammy if you ask me.
>
> Why do they do this?  2 reasons: 1, "supposedly" having more followers
> means more visits and clicks in whatever you're trying to promote. (I don't
> believe this)  and 2, many of these people also have auto-DM set up to send
> links and messages to each person that follows them back.  Back when I
> offered this service (we disabled it for this exact reason) people told me
> they were seeing significant clicks on the links they would send to people
> via DM after they followed them.  Therefore, more follows==more clicks==more
> revenue. I don't blame them if that's what they're really seeing.
>
> So for this reason I think having limits in place is a *good* thing.  I
> don't think the follow limit is in place due to traffic reasons, since there
> are many more calls that cause more traffic on the API and there is no limit
> to unfollows, so I really think Twitter is doing this for the purpose of
> reducing spam and "gaming" of Twitter.  This is a good thing.
>
> However, I think Twitter may be approaching the limits the wrong way.
>  Here's what I think would be more effective, and beneficial for the
> legitimate users that want to follow back and at the same time not allow
> those who want to game the system to use the methods I described.  Twitter
> needs to impose limits based on whether the individual is following the user
> back or not.
>
> For instance, if I follow @dacort and he is following me back, that
> shouldn't count against me as a hit against my follow limit.  However, if I
> try to follow @dacort and he is not following me back, it should count
> against me as a hit against my limit.  With this, users could easily
> auto-follow back if they choose to, and it would still be difficult for the
> users trying to game the system and spam Twitter.  In fact, you could
> significantly *reduce* the limit this way and make it virtually impossible
> for these users to use Twitter in that manner.  If you were to look at the
> relationship between the users when counting against limits, you could
> probably reduce the follow/day limit all the way to around 200 per day
> instead of 1,000 per day.  I don't see any reason for the 10%
> follow/follower ratio with a low limit such as that.
>
> However, as stands, the more followers you get, if you are using Twitter
> legitimately, you have no way to extend the courtesy back if you choose to
> do so, since after a certain point you will be following many more than
> 1,000 users per day.  And even if you aren't, it will take an extremely long
> time for many individuals to finally catch up to follow those following them
> if they want to at 1,000 follows per day.
>
> I know there are some that disagree with the auto-follow concept.  However,
> I also know most of you also want Twitter to be an open environment where
> people can choose to use it as they please.  Doug, Alex, etc. I'd love it if
> you guys could at least consider changing the follow limits as I mentioned.

[twitter-dev] Follow Limits - a Discussion

Let's discuss the follow limits.  I feel, as developer of a tool that allows
people to auto-follow, I have a bit of insight into this.  While there are
many, many legitimate users that auto-follow others, and have good reason to
do so, some are using it as a way to game the system, build followers
quickly, break the Twitter TOS, and reduce the meaning of follower numbers
for many other users just using the service legitimately.  I see this daily,
amongst a few of my own users, and while, due to our privacy policy I can't
share who they are, I do have some suggestions that would make the API
follow limits make a little more sense.  Maybe you guys can provide more
insight.

-Currently the follow per day limit is 1,000 follows per user per day.
 There is no limit on the number of unfollows a user can do per day (that I
know of), and it appears as though there is also a limit of around 10% for
the number of users a person can follow more than follow them back.  The
users taking advantage of Twitter have figured this out.  So here's what
they do:

A "gamer"'s typical activity is that they will follow as many people as they
can - most up to the 1,000 limit they're allowed per day, until they hit the
ratio of 10%.  The higher the follower base they gain, the longer they're
able to do this.  They then hope a good portion of those 1,000 people follow
back.  Those that don't use tools like mine (which weren't intended to be
used this way) to unfollow everyone who is not following them back.  This is
often much greater than 1,000 for the users that are really good at it.  The
process then starts over.  They'll use tools like Hummingbird (Google it)
and Twollo to find people and automatically go out and follow them.  This is
why I refuse to create auto-follow filters to find new people on my service.
It's way too spammy if you ask me.

Why do they do this?  2 reasons: 1, "supposedly" having more followers means
more visits and clicks in whatever you're trying to promote. (I don't
believe this)  and 2, many of these people also have auto-DM set up to send
links and messages to each person that follows them back.  Back when I
offered this service (we disabled it for this exact reason) people told me
they were seeing significant clicks on the links they would send to people
via DM after they followed them.  Therefore, more follows==more clicks==more
revenue. I don't blame them if that's what they're really seeing.

So for this reason I think having limits in place is a *good* thing.  I
don't think the follow limit is in place due to traffic reasons, since there
are many more calls that cause more traffic on the API and there is no limit
to unfollows, so I really think Twitter is doing this for the purpose of
reducing spam and "gaming" of Twitter.  This is a good thing.

However, I think Twitter may be approaching the limits the wrong way.
 Here's what I think would be more effective, and beneficial for the
legitimate users that want to follow back and at the same time not allow
those who want to game the system to use the methods I described.  Twitter
needs to impose limits based on whether the individual is following the user
back or not.

For instance, if I follow @dacort and he is following me back, that
shouldn't count against me as a hit against my follow limit.  However, if I
try to follow @dacort and he is not following me back, it should count
against me as a hit against my limit.  With this, users could easily
auto-follow back if they choose to, and it would still be difficult for the
users trying to game the system and spam Twitter.  In fact, you could
significantly *reduce* the limit this way and make it virtually impossible
for these users to use Twitter in that manner.  If you were to look at the
relationship between the users when counting against limits, you could
probably reduce the follow/day limit all the way to around 200 per day
instead of 1,000 per day.  I don't see any reason for the 10%
follow/follower ratio with a low limit such as that.

However, as stands, the more followers you get, if you are using Twitter
legitimately, you have no way to extend the courtesy back if you choose to
do so, since after a certain point you will be following many more than
1,000 users per day.  And even if you aren't, it will take an extremely long
time for many individuals to finally catch up to follow those following them
if they want to at 1,000 follows per day.

I know there are some that disagree with the auto-follow concept.  However,
I also know most of you also want Twitter to be an open environment where
people can choose to use it as they please.  Doug, Alex, etc. I'd love it if
you guys could at least consider changing the follow limits as I mentioned.
 The current limits are doing nothing to prevent the spammers - my
suggestions I believe will, and will keep it an open environment for the
rest of us.

Sorry for the long discourse - I would really love to hear others thoughts
and suggestions.

@Jesse

[twitter-dev] Re: Streaming API -- /follow /birddog and /shadow also match in_reply_to field.


Makes sense.

One thing I'm noticing that now this feature is live:

If userA and userB are both in my follow id list, and then if userA
makes an explicit reply to userB, I get userA's update twice.  Just
something to be aware of for everyone.

This "duplicate update" also happens if you have the same user id
listed twice (or more) in the follow id list.  I found this out by
merging two follow lists which overlapped.  'sort' and 'uniq' became
my friends soon thereafter.

-Chad

On Tue, Jun 9, 2009 at 11:24 PM, John Kalucki  wrote:
>
> Unlikely.
>
> In general, we treat a status as immutable, but removable.
> Hosebird doesn't re-write statuses.
> Clients can determine this by themselves.
> Too many other things to do!
>
> -John
>
>
> On Jun 9, 8:10 pm, Chad Etzel  wrote:
>> Neato!
>>
>> Would it be possible to add some sort of attribute to the status
>> object which indicates when this is the case? (i.e. this update is
>> being sent to you, but the user id of the sender is not explicitly in
>> the follow id list?)
>>
>> Would be handy, perhaps.
>> -Chad
>>
>> On Tue, Jun 9, 2009 at 10:46 PM, John Kalucki  wrote:
>>
>> > The follow by userID resources, /follow, /birddog and /shadow, stream
>> > all public statuses filtered by a list of userIDs. In addition to
>> > updates created by users in the list, explicit replies now also match
>> > and are streamed to consumers.
>>
>> > Mentions, statuses that contain a given screen name ("Hello @user!"),
>> > but aren't explicit replies, are not matched.
>>
>> > -John Kalucki
>> > Services, Twitter Inc.

[twitter-dev] Re: Streaming API -- /follow /birddog and /shadow also match in_reply_to field.

2009-06-09 Thread John Kalucki


Unlikely.

In general, we treat a status as immutable, but removable.
Hosebird doesn't re-write statuses.
Clients can determine this by themselves.
Too many other things to do!

-John


On Jun 9, 8:10 pm, Chad Etzel  wrote:
> Neato!
>
> Would it be possible to add some sort of attribute to the status
> object which indicates when this is the case? (i.e. this update is
> being sent to you, but the user id of the sender is not explicitly in
> the follow id list?)
>
> Would be handy, perhaps.
> -Chad
>
> On Tue, Jun 9, 2009 at 10:46 PM, John Kalucki  wrote:
>
> > The follow by userID resources, /follow, /birddog and /shadow, stream
> > all public statuses filtered by a list of userIDs. In addition to
> > updates created by users in the list, explicit replies now also match
> > and are streamed to consumers.
>
> > Mentions, statuses that contain a given screen name ("Hello @user!"),
> > but aren't explicit replies, are not matched.
>
> > -John Kalucki
> > Services, Twitter Inc.

[twitter-dev] Re: Streaming API -- /follow /birddog and /shadow also match in_reply_to field.

Neato!

Would it be possible to add some sort of attribute to the status
object which indicates when this is the case? (i.e. this update is
being sent to you, but the user id of the sender is not explicitly in
the follow id list?)

Would be handy, perhaps.
-Chad

On Tue, Jun 9, 2009 at 10:46 PM, John Kalucki  wrote:
>
> The follow by userID resources, /follow, /birddog and /shadow, stream
> all public statuses filtered by a list of userIDs. In addition to
> updates created by users in the list, explicit replies now also match
> and are streamed to consumers.
>
> Mentions, statuses that contain a given screen name ("Hello @user!"),
> but aren't explicit replies, are not matched.
>
> -John Kalucki
> Services, Twitter Inc.
>
>

[twitter-dev] Streaming API -- /follow /birddog and /shadow also match in_reply_to field.

2009-06-09 Thread John Kalucki


The follow by userID resources, /follow, /birddog and /shadow, stream
all public statuses filtered by a list of userIDs. In addition to
updates created by users in the list, explicit replies now also match
and are streamed to consumers.

Mentions, statuses that contain a given screen name ("Hello @user!"),
but aren't explicit replies, are not matched.

-John Kalucki
Services, Twitter Inc.

[twitter-dev] Re: Twitter Application Usage Guidelines, Please Read

2009-06-09 Thread Developer In London

I second that.

2009/6/10 Justyn Howard 

>  What are the chances that this new TOS will negate any of the hard work
> we’ve done up until this point? Can you give us an idea of what will be
> protected? It’s a little alarming to hear that Twitter might decide to
> reserve functionality that the developer network has built-on and enhanced
> in favor of internalizing as business assets. As there has been no TOS in
> place other than the general Twitter TOS, many of us have spent countless
> hours and $$ trying to build businesses around Twitter.
>
> Not trying to be an alarmist, just curious what this will ultimately mean
> for us?
>
> Justyn
>
>
> On 6/9/09 8:51 PM, "Doug Williams"  wrote:
>
> The API TOS is currently in development. It is taking longer than hoped as
> we are still exploring what we want to give to developers and what we want
> to protect as business assets. For now, make sure that you understand the
> general TOS we have in place.
>
> We do work with developers if they are willing to answer our attempts to
> reach out before shutting them off due to TOS violations. We also try to
> understand what developers are doing and how they may be heading against the
> grain before issuing whitelisting. Most developers are willing to work with
> us which is great and works out for everyone.
>
> Thanks,
> Doug
>
>
>
> On Tue, Jun 9, 2009 at 6:26 PM, Jesse Stay  wrote:
>
> Doug, where is the developer API TOS?  I think that's part of the problem -
> none of us are being required to enter into an agreement before
> developing, therefore we have no idea what we can and can't do with it.  I
> also don't think most of us even know where any such TOS is, if there is
> one.  I agree that the OAuth application process should make this a bit 
> easier to manage,
> and help developers know more about what they are getting into before
> starting their applications.
>
> Personally, I want to make sure I'm following the rules of the
> API.  I'd also prefer to know what I'm agreeing to before starting a business 
> on top of it.
>  I feel for the developers of the 2 mentioned apps because, *if* they are
> violating any TOS, they probably had no idea they were doing so before
> spending so much time developing it. (even if I disagree with the premise of
> those apps)
>
> @Jesse
>
>
> On Tue, Jun 9, 2009 at 5:31 PM, Doug Williams  wrote:
>
> Brant,
> Thank you for your concern. This is something that bothers us as well.
>
> Moving applications exclusively to OAuth-based authentication will
> certainly help in restricting applications that abuse the service. If you
> find a service that you think is violating our TOS, please email
> a...@twitter.com or send a message to @twitterapi and we can take a look.
> As you mentioned, Del is great but she is but one person. We do have an
> abuse team forming to help quickly identify which services are violating our
> TOS. All in all we have a lot of work to do so please do help where you can.
>
> Cheers,
> Doug
>
>
> On Tue, Jun 9, 2009 at 2:43 PM, Brant  wrote:
>
>
> This message will hopefully get back to the people who run Twitter API
> development and spam prevention.
>
> I noticed there are quite a few twitter applications that are
> developed to abuse the service and violate their TOS.  They do not
> hide what their purpose is, yet these applications remain active.  I
> contacted twitter.com/delbius   who heads
> Twitter Spam prevention and
> she said that they do revoke API access to abusive applications.  But
> I don't think they are taking an aggressive stance against them.
>
> Abusive Applications:
> http://www.huitter.com/mutuality/
> http://www.twollo.com/
>
> The combination of these two applications is for outright abuse of the
> service.  They have been around for several months and are known
> applications to abuse the service with.  To make matters worse,
> Twitter suspends accounts of the people who use these applications
> rather than targeting the root of the problem, the applications
> themselves.  (Sound counterproductive? RIAA uses a similar policy by
> going after end users.)
>
> I propose that applications need to be more closely scrutinized and
> can even be flagged as abusive by users. Instead of creating
> algorithms that detect abnormal user behavior, why not detect abnormal
> application behavior.
>
> Taking a stronger stance against gray area applications could reduce
> server load on Twitter (giving real applications faster response time)
> and reduce manpower to deal with spam prevention.
>
> I strongly encourage anyone who develops Twitter applications to send
> this link around.
>
> Thanks for reading,
> Brant
> twitter.com/BrantTedeschi 
>
>
>
>
>
>


-- 
cashflowclublondon.co.uk

  ("`-''-/").___..--''"`-._
   `6_ 6  )   `-.  ( ).`-.__.`)
   (_Y_.)'  ._   )  `._ `. ``-..-'
 _..`--'_..-_/  /--'_.'

[twitter-dev] Re: Twitter Application Usage Guidelines, Please Read

Obviously I can't address the impact since we don't have a document
to deliver. Let me be clear, we are not thinking of taking functionality
from the offering, but we are discussing how open we want to be moving
forward. Most of the talks are around what we want to offer through the
Streaming API and to whom should those privileges be extended. We are not
concentrating our efforts on whom can we restrict and why? Remember we built
this company on being open and to that we are committed, especially within
the API team. We are very conscious that you developers are a little weary
of our plans but rest assured we want to augment the ecosystem and its
abilities rather than contract our offering.
Thanks,
Doug



On Tue, Jun 9, 2009 at 6:58 PM, Justyn Howard wrote:

>  What are the chances that this new TOS will negate any of the hard work
> we’ve done up until this point? Can you give us an idea of what will be
> protected? It’s a little alarming to hear that Twitter might decide to
> reserve functionality that the developer network has built-on and enhanced
> in favor of internalizing as business assets. As there has been no TOS in
> place other than the general Twitter TOS, many of us have spent countless
> hours and $$ trying to build businesses around Twitter.
>
> Not trying to be an alarmist, just curious what this will ultimately mean
> for us?
>
> Justyn
>
>
> On 6/9/09 8:51 PM, "Doug Williams"  wrote:
>
> The API TOS is currently in development. It is taking longer than hoped as
> we are still exploring what we want to give to developers and what we want
> to protect as business assets. For now, make sure that you understand the
> general TOS we have in place.
>
> We do work with developers if they are willing to answer our attempts to
> reach out before shutting them off due to TOS violations. We also try to
> understand what developers are doing and how they may be heading against the
> grain before issuing whitelisting. Most developers are willing to work with
> us which is great and works out for everyone.
>
> Thanks,
> Doug
>
>
>
> On Tue, Jun 9, 2009 at 6:26 PM, Jesse Stay  wrote:
>
> Doug, where is the developer API TOS?  I think that's part of the problem -
> none of us are being required to enter into an agreement before
> developing, therefore we have no idea what we can and can't do with it.  I
> also don't think most of us even know where any such TOS is, if there is
> one.  I agree that the OAuth application process should make this a bit 
> easier to manage,
> and help developers know more about what they are getting into before
> starting their applications.
>
> Personally, I want to make sure I'm following the rules of the
> API.  I'd also prefer to know what I'm agreeing to before starting a business 
> on top of it.
>  I feel for the developers of the 2 mentioned apps because, *if* they are
> violating any TOS, they probably had no idea they were doing so before
> spending so much time developing it. (even if I disagree with the premise of
> those apps)
>
> @Jesse
>
>
> On Tue, Jun 9, 2009 at 5:31 PM, Doug Williams  wrote:
>
> Brant,
> Thank you for your concern. This is something that bothers us as well.
>
> Moving applications exclusively to OAuth-based authentication will
> certainly help in restricting applications that abuse the service. If you
> find a service that you think is violating our TOS, please email
> a...@twitter.com or send a message to @twitterapi and we can take a look.
> As you mentioned, Del is great but she is but one person. We do have an
> abuse team forming to help quickly identify which services are violating our
> TOS. All in all we have a lot of work to do so please do help where you can.
>
> Cheers,
> Doug
>
>
> On Tue, Jun 9, 2009 at 2:43 PM, Brant  wrote:
>
>
> This message will hopefully get back to the people who run Twitter API
> development and spam prevention.
>
> I noticed there are quite a few twitter applications that are
> developed to abuse the service and violate their TOS.  They do not
> hide what their purpose is, yet these applications remain active.  I
> contacted twitter.com/delbius   who heads
> Twitter Spam prevention and
> she said that they do revoke API access to abusive applications.  But
> I don't think they are taking an aggressive stance against them.
>
> Abusive Applications:
> http://www.huitter.com/mutuality/
> http://www.twollo.com/
>
> The combination of these two applications is for outright abuse of the
> service.  They have been around for several months and are known
> applications to abuse the service with.  To make matters worse,
> Twitter suspends accounts of the people who use these applications
> rather than targeting the root of the problem, the applications
> themselves.  (Sound counterproductive? RIAA uses a similar policy by
> going after end users.)
>
> I propose that applications need to be more closely scrutinized and
> can even be flagged as abusive by users. Instead of creating
>

[twitter-dev] Re: Twitter Application Usage Guidelines, Please Read

2009-06-09 Thread Justyn Howard

What are the chances that this new TOS will negate any of the hard work
we¹ve done up until this point? Can you give us an idea of what will be
protected? It¹s a little alarming to hear that Twitter might decide to
reserve functionality that the developer network has built-on and enhanced
in favor of internalizing as business assets. As there has been no TOS in
place other than the general Twitter TOS, many of us have spent countless
hours and $$ trying to build businesses around Twitter.

Not trying to be an alarmist, just curious what this will ultimately mean
for us?

Justyn

On 6/9/09 8:51 PM, "Doug Williams"  wrote:

> The API TOS is currently in development. It is taking longer than hoped as we
> are still exploring what we want to give to developers and what we want to
> protect as business assets. For now, make sure that you understand the
> general TOS we have in place. 
> 
> We do work with developers if they are willing to answer our attempts to reach
> out before shutting them off due to TOS violations. We also try to understand
> what developers are doing and how they may be heading against the grain before
> issuing whitelisting. Most developers are willing to work with us which is
> great and works out for everyone.
> 
> Thanks,
> Doug
> 
> 
> 
> On Tue, Jun 9, 2009 at 6:26 PM, Jesse Stay  wrote:
>> Doug, where is the developer API TOS?  I think that's part of the problem -
>> none of us are being required to enter into an agreement before
>> developing, therefore we have no idea what we can and can't do with it.  I
>> also don't think most of us even know where any such TOS is, if there is
>> one.  I agree that the OAuth application process should make this a bit easie
>> r to manage, and help developers know more about what they are getting into
>> before starting their applications.
>> 
>> Personally, I want to make sure I'm following the rules of the
>> API.  I'd also prefer to know what I'm agreeing to before starting a business
>>  on top of it.  I feel for the developers of the 2 mentioned apps because,
>> *if* they are violating any TOS, they probably had no idea they were doing so
>> before spending so much time developing it. (even if I disagree with the
>> premise of those apps)
>> 
>> @Jesse
>> 
>> 
>> On Tue, Jun 9, 2009 at 5:31 PM, Doug Williams  wrote:
>>> Brant,
>>> Thank you for your concern. This is something that bothers us as well.
>>> 
>>> Moving applications exclusively to OAuth-based authentication will certainly
>>> help in restricting applications that abuse the service. If you find a
>>> service that you think is violating our TOS, please email a...@twitter.com 
>>> or
>>> send a message to @twitterapi and we can take a look. As you mentioned, Del
>>> is great but she is but one person. We do have an abuse team forming to help
>>> quickly identify which services are violating our TOS. All in all we have a
>>> lot of work to do so please do help where you can.
>>> 
>>> Cheers,
>>> Doug
>>> 
>>> 
>>> On Tue, Jun 9, 2009 at 2:43 PM, Brant  wrote:

 This message will hopefully get back to the people who run Twitter API
 development and spam prevention.

 I noticed there are quite a few twitter applications that are
 developed to abuse the service and violate their TOS.  They do not
 hide what their purpose is, yet these applications remain active.  I
 contacted twitter.com/delbius   who heads
 Twitter Spam prevention and
 she said that they do revoke API access to abusive applications.  But
 I don't think they are taking an aggressive stance against them.

 Abusive Applications:
 http://www.huitter.com/mutuality/
 http://www.twollo.com/

 The combination of these two applications is for outright abuse of the
 service.  They have been around for several months and are known
 applications to abuse the service with.  To make matters worse,
 Twitter suspends accounts of the people who use these applications
 rather than targeting the root of the problem, the applications
 themselves.  (Sound counterproductive? RIAA uses a similar policy by
 going after end users.)

 I propose that applications need to be more closely scrutinized and
 can even be flagged as abusive by users. Instead of creating
 algorithms that detect abnormal user behavior, why not detect abnormal
 application behavior.

 Taking a stronger stance against gray area applications could reduce
 server load on Twitter (giving real applications faster response time)
 and reduce manpower to deal with spam prevention.

 I strongly encourage anyone who develops Twitter applications to send
 this link around.

 Thanks for reading,
 Brant
 twitter.com/BrantTedeschi 
>>> 
>> 
> 
>

[twitter-dev] Re: Twitter Application Usage Guidelines, Please Read

2009-06-09 Thread Caliban Darklock


On Tue, Jun 9, 2009 at 5:27 PM, Brant wrote:
>
> Williams, my point is why would a user need to rapidly remove or add
> twitter followers?

Turn that around: why should a user be FORBIDDEN to rapidly remove or
add new followers?

[twitter-dev] Re: Twitter Application Usage Guidelines, Please Read

The API TOS is currently in development. It is taking longer than hoped as
we are still exploring what we want to give to developers and what we want
to protect as business assets. For now, make sure that you understand the
general TOS we have in place.
We do work with developers if they are willing to answer our attempts to
reach out before shutting them off due to TOS violations. We also try to
understand what developers are doing and how they may be heading against the
grain before issuing whitelisting. Most developers are willing to work with
us which is great and works out for everyone.

Thanks,
Doug



On Tue, Jun 9, 2009 at 6:26 PM, Jesse Stay  wrote:

> Doug, where is the developer API TOS?  I think that's part of the problem -
> none of us are being required to enter into an agreement before
> developing, therefore we have no idea what we can and can't do with it.  I
> also don't think most of us even know where any such TOS is, if there is
> one.  I agree that the OAuth application process should make this a bit 
> easier to manage,
> and help developers know more about what they are getting into before
> starting their applications.
> Personally, I want to make sure I'm following the rules of the
> API.  I'd also prefer to know what I'm agreeing to before starting a business 
> on top of it.
>  I feel for the developers of the 2 mentioned apps because, *if* they are
> violating any TOS, they probably had no idea they were doing so before
> spending so much time developing it. (even if I disagree with the premise of
> those apps)
>
> @Jesse
>
>
> On Tue, Jun 9, 2009 at 5:31 PM, Doug Williams  wrote:
>
>> Brant,Thank you for your concern. This is something that bothers us as
>> well.
>>
>> Moving applications exclusively to OAuth-based authentication will
>> certainly help in restricting applications that abuse the service. If you
>> find a service that you think is violating our TOS, please email
>> a...@twitter.com or send a message to @twitterapi and we can take a look.
>> As you mentioned, Del is great but she is but one person. We do have an
>> abuse team forming to help quickly identify which services are violating our
>> TOS. All in all we have a lot of work to do so please do help where you can.
>>
>> Cheers,
>> Doug
>>
>>
>> On Tue, Jun 9, 2009 at 2:43 PM, Brant  wrote:
>>
>>>
>>> This message will hopefully get back to the people who run Twitter API
>>> development and spam prevention.
>>>
>>> I noticed there are quite a few twitter applications that are
>>> developed to abuse the service and violate their TOS.  They do not
>>> hide what their purpose is, yet these applications remain active.  I
>>> contacted twitter.com/delbius who heads Twitter Spam prevention and
>>> she said that they do revoke API access to abusive applications.  But
>>> I don't think they are taking an aggressive stance against them.
>>>
>>> Abusive Applications:
>>> http://www.huitter.com/mutuality/
>>> http://www.twollo.com/
>>>
>>> The combination of these two applications is for outright abuse of the
>>> service.  They have been around for several months and are known
>>> applications to abuse the service with.  To make matters worse,
>>> Twitter suspends accounts of the people who use these applications
>>> rather than targeting the root of the problem, the applications
>>> themselves.  (Sound counterproductive? RIAA uses a similar policy by
>>> going after end users.)
>>>
>>> I propose that applications need to be more closely scrutinized and
>>> can even be flagged as abusive by users. Instead of creating
>>> algorithms that detect abnormal user behavior, why not detect abnormal
>>> application behavior.
>>>
>>> Taking a stronger stance against gray area applications could reduce
>>> server load on Twitter (giving real applications faster response time)
>>> and reduce manpower to deal with spam prevention.
>>>
>>> I strongly encourage anyone who develops Twitter applications to send
>>> this link around.
>>>
>>> Thanks for reading,
>>> Brant
>>> twitter.com/BrantTedeschi
>>>
>>
>>
>

[twitter-dev] Re: Twitter Application Usage Guidelines, Please Read

Doug, where is the developer API TOS?  I think that's part of the problem -
none of us are being required to enter into an agreement before
developing, therefore we have no idea what we can and can't do with it.  I
also don't think most of us even know where any such TOS is, if there is
one.  I agree that the OAuth application process should make this a
bit easier to manage,
and help developers know more about what they are getting into before
starting their applications.
Personally, I want to make sure I'm following the rules of the
API.  I'd also prefer to know what I'm agreeing to before starting a
business on top of it.
 I feel for the developers of the 2 mentioned apps because, *if* they are
violating any TOS, they probably had no idea they were doing so before
spending so much time developing it. (even if I disagree with the premise of
those apps)

@Jesse

On Tue, Jun 9, 2009 at 5:31 PM, Doug Williams  wrote:

> Brant,Thank you for your concern. This is something that bothers us as
> well.
>
> Moving applications exclusively to OAuth-based authentication will
> certainly help in restricting applications that abuse the service. If you
> find a service that you think is violating our TOS, please email
> a...@twitter.com or send a message to @twitterapi and we can take a look.
> As you mentioned, Del is great but she is but one person. We do have an
> abuse team forming to help quickly identify which services are violating our
> TOS. All in all we have a lot of work to do so please do help where you can.
>
> Cheers,
> Doug
>
>
> On Tue, Jun 9, 2009 at 2:43 PM, Brant  wrote:
>
>>
>> This message will hopefully get back to the people who run Twitter API
>> development and spam prevention.
>>
>> I noticed there are quite a few twitter applications that are
>> developed to abuse the service and violate their TOS.  They do not
>> hide what their purpose is, yet these applications remain active.  I
>> contacted twitter.com/delbius who heads Twitter Spam prevention and
>> she said that they do revoke API access to abusive applications.  But
>> I don't think they are taking an aggressive stance against them.
>>
>> Abusive Applications:
>> http://www.huitter.com/mutuality/
>> http://www.twollo.com/
>>
>> The combination of these two applications is for outright abuse of the
>> service.  They have been around for several months and are known
>> applications to abuse the service with.  To make matters worse,
>> Twitter suspends accounts of the people who use these applications
>> rather than targeting the root of the problem, the applications
>> themselves.  (Sound counterproductive? RIAA uses a similar policy by
>> going after end users.)
>>
>> I propose that applications need to be more closely scrutinized and
>> can even be flagged as abusive by users. Instead of creating
>> algorithms that detect abnormal user behavior, why not detect abnormal
>> application behavior.
>>
>> Taking a stronger stance against gray area applications could reduce
>> server load on Twitter (giving real applications faster response time)
>> and reduce manpower to deal with spam prevention.
>>
>> I strongly encourage anyone who develops Twitter applications to send
>> this link around.
>>
>> Thanks for reading,
>> Brant
>> twitter.com/BrantTedeschi
>>
>
>

[twitter-dev] Re: Twitter Application Usage Guidelines, Please Read

2009-06-09 Thread Brant


I agree with you Justyn.  There are probably tons of applications, but
these two were on the top of my head.

If a large amount of users are getting banned for using a particular
service then Twitter should recognize a pattern and give the service
notification of the issue and give them some time to address it.  If
user abuse continues then their access should be revoked for the good
of the service.

On Jun 9, 7:35 pm, Justyn Howard  wrote:
> I think it depends on what measures the site is taking to promote
> responsible use of the applications. Both applications could be used for
> good, or bad. I can think of one fairly popular site that is all but
> endorses spammy behavior and charges users for access to these spammy tools.
> I don¹t want to point fingers, but my point is, there are probably more
> abusive apps out there than these two, and it all comes down to how
> responsibly the sites are guiding users, and if they have any rules in place
> to get rid of those who abuse it.
>
> On 6/9/09 6:28 PM, "Abraham Williams" <4bra...@gmail.com> wrote:
>
> > In briefly checking out Mutuality and Twollo I'm not sure what about them is
> > abusive. Mutuality says it lets you rapidly modify who you are following to
> > match who is following you and Twollo auto follows accounts it thinks you
> > might be interested in. Those are both useful
> > tools and if used as intended are just that. I can see Twitter banning an
> > individual user for using the services abusively but not the services
> > themselves. 
>
> > On Tue, Jun 9, 2009 at 16:43, Brant  wrote:
>
> >> This message will hopefully get back to the people who run Twitter API
> >> development and spam prevention.
>
> >> I noticed there are quite a few twitter applications that are
> >> developed to abuse the service and violate their TOS.  They do not
> >> hide what their purpose is, yet these applications remain active.  I
> >> contacted twitter.com/delbius   who heads 
> >> Twitter
> >> Spam prevention and
> >> she said that they do revoke API access to abusive applications.  But
> >> I don't think they are taking an aggressive stance against them.
>
> >> Abusive Applications:
> >>http://www.huitter.com/mutuality/
> >>http://www.twollo.com/
>
> >> The combination of these two applications is for outright abuse of the
> >> service.  They have been around for several months and are known
> >> applications to abuse the service with.  To make matters worse,
> >> Twitter suspends accounts of the people who use these applications
> >> rather than targeting the root of the problem, the applications
> >> themselves.  (Sound counterproductive? RIAA uses a similar policy by
> >> going after end users.)
>
> >> I propose that applications need to be more closely scrutinized and
> >> can even be flagged as abusive by users. Instead of creating
> >> algorithms that detect abnormal user behavior, why not detect abnormal
> >> application behavior.
>
> >> Taking a stronger stance against gray area applications could reduce
> >> server load on Twitter (giving real applications faster response time)
> >> and reduce manpower to deal with spam prevention.
>
> >> I strongly encourage anyone who develops Twitter applications to send
> >> this link around.
>
> >> Thanks for reading,
> >> Brant
> >> twitter.com/BrantTedeschi

[twitter-dev] Re: Twitter Application Usage Guidelines, Please Read

2009-06-09 Thread Brant


Williams, my point is why would a user need to rapidly remove or add
twitter followers?  Mutuality even states that it is not responsible
if your twitter account gets suspended for using their service.  The
underlying usage for these services is for abuse.

I ordinarily wouldn't mind but the reason I care is that I think these
types of services are using up resources that Twitter just can't
afford to waste.

On Jun 9, 7:28 pm, Abraham Williams <4bra...@gmail.com> wrote:
> In briefly checking out Mutuality and Twollo I'm not sure what about them is
> abusive. Mutuality says it lets you rapidly modify who you are following to
> match who is following you and Twollo auto follows accounts it thinks you
> might be interested in. Those are both useful
> tools and if used as intended are just that. I can see Twitter banning an
> individual user for using the services abusively but not the services
> themselves.
>
>
>
> On Tue, Jun 9, 2009 at 16:43, Brant  wrote:
>
> > This message will hopefully get back to the people who run Twitter API
> > development and spam prevention.
>
> > I noticed there are quite a few twitter applications that are
> > developed to abuse the service and violate their TOS.  They do not
> > hide what their purpose is, yet these applications remain active.  I
> > contacted twitter.com/delbius who heads Twitter Spam prevention and
> > she said that they do revoke API access to abusive applications.  But
> > I don't think they are taking an aggressive stance against them.
>
> > Abusive Applications:
> >http://www.huitter.com/mutuality/
> >http://www.twollo.com/
>
> > The combination of these two applications is for outright abuse of the
> > service.  They have been around for several months and are known
> > applications to abuse the service with.  To make matters worse,
> > Twitter suspends accounts of the people who use these applications
> > rather than targeting the root of the problem, the applications
> > themselves.  (Sound counterproductive? RIAA uses a similar policy by
> > going after end users.)
>
> > I propose that applications need to be more closely scrutinized and
> > can even be flagged as abusive by users. Instead of creating
> > algorithms that detect abnormal user behavior, why not detect abnormal
> > application behavior.
>
> > Taking a stronger stance against gray area applications could reduce
> > server load on Twitter (giving real applications faster response time)
> > and reduce manpower to deal with spam prevention.
>
> > I strongly encourage anyone who develops Twitter applications to send
> > this link around.
>
> > Thanks for reading,
> > Brant
> > twitter.com/BrantTedeschi
>
> --
> Abraham Williams | Community |http://web608.org
> Hacker |http://abrah.am|http://twitter.com/abraham
> Project |http://fireeagle.labs.poseurtech.com
> This email is: [ ] blogable [x] ask first [ ] private.

[twitter-dev] Re: Purposed method: friendships/show


If adding the other states (pending, blocked, etc) then I would agree
with the "redundancy" by having all attributes present in both
"source" and "target" objects.  These relationships are not
necessarily symmetric, so it makes sense to have them in each object
since they would not necessarily be redundant.

-Chad

On Tue, Jun 9, 2009 at 8:22 PM, Marcel Molina  wrote:
> Good point about pending requests for protected accounts and the opportunity
> to get parity.
> My inclination is rather than overloading following and followed_by that we
> potentially introduce a 'pending' attribute that is either true or empty.
> Similarly we could add a 'blocked'/'blocked_by'.
> These additional attributes sway me toward going with the
> representation that (redundantly) specifies the values of each attribute with the source and target sections as encoding this information in 'source_has_a_pending_request_for_target' and 'target_has_a_pending_request_for_source', etc start to get somewhat unwieldy.
>
> On Tue, Jun 9, 2009 at 4:29 PM, jim.renkel  wrote:
>>
>> It seems from the examples, but not explicitly stated anywhere, that
>> the values of the following and followed_by items are booleans,
>> implying that a user either is or is not following another user.
>>
>> While at first blush that seems true, I think in reality the situation
>> is a little more complicated, especially if you consider protected
>> users.
>>
>> I would propose that these items be enumerations, with the following
>> values and meanings:
>> - "yes": user A, say, is following user B;
>> - "no": user A is not following user B, has not requested the
>> relationship, and is not blocked from doing so;
>> - "pending": user A has requested to follow (protected) user B, but B
>> has not yet accepted, rejected, or blocked the request; and
>> - "blocked": user A requested to follow (protected) user B, but B
>> blocked the request.
>>
>> What I'm looking for here is parity, if you will, between the data and
>> facilities that are available to the twitter.com web site and to API
>> users. This is one place where there was not parity, and we have the
>> opportunity to now get it.
>>
>> Comments expected, welcome, and appreciated.
>>
>> Jim Renkel
>>
>> On Jun 9, 1:13 pm, Damon Clinkscales  wrote:
>> > If you're going to redefine the way that follow information is
>> > returned, I believe that it should include the effect of "protected"
>> > accounts on both sides of the follow equation.
>> >
>> > Thanks,
>> > -damon
>> > --http://twitter.com/damon
>> >
>> > On Tue, Jun 9, 2009 at 10:52 AM, Marcel Molina
>> > wrote:
>> > > Thanks for the suggestion Chad.
>> > > What do others think of
>> > > {"relationship": {
>> > >  "source": {
>> > >    "id": 123,
>> > >    "screen_name": "bob",
>> > >    "notifications": false },
>> >
>> > >  "target": {
>> > >    "id": 456,
>> > >    "screen_name": "jack",
>> > >    "notifications": null },
>> >
>> > >  "source_follows_target": true,
>> > >  "source_followed_by_target": false
>> > > }
>> > > }
>> > > versus
>> >
>> > > {"relationship": {
>> >
>> > > "source": {
>> >
>> > > "id": 123,
>> >
>> > > "screen_name": "bob",
>> >
>> > > "following": true,
>> >
>> > > "followed_by": false,
>> >
>> > > "notifications_enabled": false },
>> >
>> > > "target": {
>> >
>> > > "id": 456,
>> >
>> > > "screen_name": "jack",
>> >
>> > > "following": false,
>> >
>> > > "followed_by": true,
>> >
>> > > "notifications_enabled": null }
>> >
>> > > }
>> >
>> > > }
>
>
>
> --
> Marcel Molina
> Twitter API Team
> http://twitter.com/noradio
>

[twitter-dev] Re: Purposed method: friendships/show

Though, it should be mentioned, w/r/t/ to pending follow requests and
blocks, you'd only get a value for those attributes for authenticated
requests where the source user is authenticated.

On Tue, Jun 9, 2009 at 5:22 PM, Marcel Molina  wrote:

> Good point about pending requests for protected accounts and the
> opportunity to get parity.
> My inclination is rather than overloading following and followed_by that we
> potentially introduce a 'pending' attribute that is either true or empty.
> Similarly we could add a 'blocked'/'blocked_by'.
>
> These additional attributes sway me toward going with the
> representation that (redundantly) specifies the values of each attribute with 
> the source and target sections as encoding this information in 
> 'source_has_a_pending_request_for_target' and 
> 'target_has_a_pending_request_for_source', etc start to get somewhat unwieldy.
>
>
> On Tue, Jun 9, 2009 at 4:29 PM, jim.renkel  wrote:
>
>>
>> It seems from the examples, but not explicitly stated anywhere, that
>> the values of the following and followed_by items are booleans,
>> implying that a user either is or is not following another user.
>>
>> While at first blush that seems true, I think in reality the situation
>> is a little more complicated, especially if you consider protected
>> users.
>>
>> I would propose that these items be enumerations, with the following
>> values and meanings:
>> - "yes": user A, say, is following user B;
>> - "no": user A is not following user B, has not requested the
>> relationship, and is not blocked from doing so;
>> - "pending": user A has requested to follow (protected) user B, but B
>> has not yet accepted, rejected, or blocked the request; and
>> - "blocked": user A requested to follow (protected) user B, but B
>> blocked the request.
>>
>> What I'm looking for here is parity, if you will, between the data and
>> facilities that are available to the twitter.com web site and to API
>> users. This is one place where there was not parity, and we have the
>> opportunity to now get it.
>>
>> Comments expected, welcome, and appreciated.
>>
>> Jim Renkel
>>
>> On Jun 9, 1:13 pm, Damon Clinkscales  wrote:
>> > If you're going to redefine the way that follow information is
>> > returned, I believe that it should include the effect of "protected"
>> > accounts on both sides of the follow equation.
>> >
>> > Thanks,
>> > -damon
>> > --http://twitter.com/damon
>> >
>> > On Tue, Jun 9, 2009 at 10:52 AM, Marcel Molina
>> wrote:
>> > > Thanks for the suggestion Chad.
>> > > What do others think of
>> > > {"relationship": {
>> > >  "source": {
>> > >"id": 123,
>> > >"screen_name": "bob",
>> > >"notifications": false },
>> >
>> > >  "target": {
>> > >"id": 456,
>> > >"screen_name": "jack",
>> > >"notifications": null },
>> >
>> > >  "source_follows_target": true,
>> > >  "source_followed_by_target": false
>> > > }
>> > > }
>> > > versus
>> >
>> > > {"relationship": {
>> >
>> > > "source": {
>> >
>> > > "id": 123,
>> >
>> > > "screen_name": "bob",
>> >
>> > > "following": true,
>> >
>> > > "followed_by": false,
>> >
>> > > "notifications_enabled": false },
>> >
>> > > "target": {
>> >
>> > > "id": 456,
>> >
>> > > "screen_name": "jack",
>> >
>> > > "following": false,
>> >
>> > > "followed_by": true,
>> >
>> > > "notifications_enabled": null }
>> >
>> > > }
>> >
>> > > }
>>
>
>
>
> --
> Marcel Molina
> Twitter API Team
> http://twitter.com/noradio
>



-- 
Marcel Molina
Twitter API Team
http://twitter.com/noradio

[twitter-dev] Re: Purposed method: friendships/show

Good point about pending requests for protected accounts and the opportunity
to get parity.
My inclination is rather than overloading following and followed_by that we
potentially introduce a 'pending' attribute that is either true or empty.
Similarly we could add a 'blocked'/'blocked_by'.

These additional attributes sway me toward going with the
representation that (redundantly) specifies the values of each
attribute with the source and target sections as encoding this
information in 'source_has_a_pending_request_for_target' and
'target_has_a_pending_request_for_source', etc start to get somewhat
unwieldy.

On Tue, Jun 9, 2009 at 4:29 PM, jim.renkel  wrote:

>
> It seems from the examples, but not explicitly stated anywhere, that
> the values of the following and followed_by items are booleans,
> implying that a user either is or is not following another user.
>
> While at first blush that seems true, I think in reality the situation
> is a little more complicated, especially if you consider protected
> users.
>
> I would propose that these items be enumerations, with the following
> values and meanings:
> - "yes": user A, say, is following user B;
> - "no": user A is not following user B, has not requested the
> relationship, and is not blocked from doing so;
> - "pending": user A has requested to follow (protected) user B, but B
> has not yet accepted, rejected, or blocked the request; and
> - "blocked": user A requested to follow (protected) user B, but B
> blocked the request.
>
> What I'm looking for here is parity, if you will, between the data and
> facilities that are available to the twitter.com web site and to API
> users. This is one place where there was not parity, and we have the
> opportunity to now get it.
>
> Comments expected, welcome, and appreciated.
>
> Jim Renkel
>
> On Jun 9, 1:13 pm, Damon Clinkscales  wrote:
> > If you're going to redefine the way that follow information is
> > returned, I believe that it should include the effect of "protected"
> > accounts on both sides of the follow equation.
> >
> > Thanks,
> > -damon
> > --http://twitter.com/damon
> >
> > On Tue, Jun 9, 2009 at 10:52 AM, Marcel Molina
> wrote:
> > > Thanks for the suggestion Chad.
> > > What do others think of
> > > {"relationship": {
> > >  "source": {
> > >"id": 123,
> > >"screen_name": "bob",
> > >"notifications": false },
> >
> > >  "target": {
> > >"id": 456,
> > >"screen_name": "jack",
> > >"notifications": null },
> >
> > >  "source_follows_target": true,
> > >  "source_followed_by_target": false
> > > }
> > > }
> > > versus
> >
> > > {"relationship": {
> >
> > > "source": {
> >
> > > "id": 123,
> >
> > > "screen_name": "bob",
> >
> > > "following": true,
> >
> > > "followed_by": false,
> >
> > > "notifications_enabled": false },
> >
> > > "target": {
> >
> > > "id": 456,
> >
> > > "screen_name": "jack",
> >
> > > "following": false,
> >
> > > "followed_by": true,
> >
> > > "notifications_enabled": null }
> >
> > > }
> >
> > > }
>



-- 
Marcel Molina
Twitter API Team
http://twitter.com/noradio

[twitter-dev] Re: PIN response in web-based OAuth app



Hi again,

Nobody is forcing you to use the PIN unless you're registered as  
a desktop app (which has no callback). The issue here is that the  
library you are using is setting a value of "oob" and specifically  
requesting the PIN flow. I have filed an issue with the gem maintainer  
on github [1] and hopefully the default can be changed. You can get  
around this right now by passing the callback into your  
get_request_token call as described in one of my previous emails.


Thanks;
 – Matt Sanford / @mzsanford
 Twitter Dev

[1] - http://github.com/mojodna/oauth/issues#issue/7

On Jun 9, 2009, at 5:15 PM, Elliott Kember wrote:



Surely this is all moot anyway - can't the OAuth process just redirect
if the application only accepts callbacks? We set a preference for
callbacks in the OAuth settings, so why are we being forced into PIN
verification?

On Jun 10, 12:46 am, lebreeze  wrote:

I managed to get the old behaviour back by modifying the oauth gem to
not set a default oauth_callback (oob)

For some reason the twitter-auth gem is not passing over the
configuration to override the default

I'm too tired to investigate further at the minute but will keep
looking in the morning (GMT)

On Jun 10, 12:16 am, Matt Sanford  wrote:




Hi there,


 I just checked the tokens generated on several of these  
services
and I see oauth_callback was set to "oob". Doug is working on the  
docs
right now to make it clear how all of this shakes out. The end  
result
is that if you want to use the pre-configured callback url don't  
send

an oauth_callback parameter at all. If you're seeing this error but
are not sending the oauth_callback parameter please email me off  
list

with a copy of the URL, headers and body where you make the
request_token call so I can try and debug the issue. It doesn't seem
to be all apps which is what I would expect in the case of a bug.



Thanks;
  – Matt Sanford / @mzsanford
  Twitter Dev



On Jun 9, 2009, at 3:53 PM, lebreeze wrote:


I'm seeing exactly the same behaviour and it just started  
happening a

few hours ago



App ishttp://moodmapr.com



Users just cannot login but instead are provided with a PIN


On Jun 9, 11:37 pm, Keith Hanson   
wrote:

I'm actually not using an oauth callback parameter and am getting
this
behavior.


I'm running on Sinatra at the moment, but have implemented my  
login

routine by pretty much copy/pasting the Rails tutorial in the API
Wiki.



I'm using the gem OAuth 0.3.5 for redirecting and what-not.



I did take a look at the redirect url, though, and didn't see any
oauth_callback params set. It sounds as if they shouldn't be there
anyways, correct?


On Jun 9, 5:28 pm, Elliott Kember   
wrote:


Sorry - having said that, I've removed the oauth_callback  
parameter
and the behaviour is still persisting - and it also doesn't  
save the

authentication so I have to hit Allow every time.


On Jun 9, 11:21 pm, Elliott Kember   
wrote:



Hey Matt,


Yep, I'm passing oauth_callback - and it does look like that's  
the
problem, because I have another app which doesn't send it, and  
it's

working fine.


Is this by design, or will it be changed back? I don't need it  
to

use
the oauth_callback url that I pass, but it'd be good to return  
to

the
specified callback URL by default.



Thanks,
Elliott



On Jun 9, 11:17 pm, Matt Sanford  wrote:



Hi there,



 Are you by chance passing anything in to the request_token
call
for the value of oauth_callback? I checked out a few other
services
and they seemed fine. If you're sending oauth_callback=oob  
(a.k.a.
"out of band") then the system is forced into the PIN flow.  
We're
working on docs for all of this now but let me know if that's  
what

you're sending.



— Matt



On Jun 9, 2009, at 2:55 PM, Keith Hanson wrote:


Same here, actually, for tweetingtoohard.com (tried to post  
here

before but it looks like it got eaten :P)



We've put up a snarky message in the meantime about the
blunders :P
But please do correct us if we have done something incorrect.



-- Keith Hanson
@big_love
keith (at) tweetingtoohard.com



On Jun 9, 4:47 pm, Elliott Kember 
wrote:

Hey guys,



I'm having a few problems with the OAuth API and my browser-
based app
- it's giving me PIN numbers at the /oauth/authorize page,  
even

though
it's set to return to a callback in the OAuth settings - I've
rechecked my settings, and the application is definitely set
as a
browser app.



I'm guessing this is something to do with the new PIN-based
desktop
app code, just wondering when it'll be fixed - or whether I'm
doing
something wrong!



Thanks,
Elliott

[twitter-dev] Re: PIN response in web-based OAuth app


Surely this is all moot anyway - can't the OAuth process just redirect
if the application only accepts callbacks? We set a preference for
callbacks in the OAuth settings, so why are we being forced into PIN
verification?

On Jun 10, 12:46 am, lebreeze  wrote:
> I managed to get the old behaviour back by modifying the oauth gem to
> not set a default oauth_callback (oob)
>
> For some reason the twitter-auth gem is not passing over the
> configuration to override the default
>
> I'm too tired to investigate further at the minute but will keep
> looking in the morning (GMT)
>
> On Jun 10, 12:16 am, Matt Sanford  wrote:
>
>
>
> > Hi there,
>
> >      I just checked the tokens generated on several of these services  
> > and I see oauth_callback was set to "oob". Doug is working on the docs  
> > right now to make it clear how all of this shakes out. The end result  
> > is that if you want to use the pre-configured callback url don't send  
> > an oauth_callback parameter at all. If you're seeing this error but  
> > are not sending the oauth_callback parameter please email me off list  
> > with a copy of the URL, headers and body where you make the  
> > request_token call so I can try and debug the issue. It doesn't seem  
> > to be all apps which is what I would expect in the case of a bug.
>
> > Thanks;
> >   – Matt Sanford / @mzsanford
> >       Twitter Dev
>
> > On Jun 9, 2009, at 3:53 PM, lebreeze wrote:
>
> > > I'm seeing exactly the same behaviour and it just started happening a
> > > few hours ago
>
> > > App ishttp://moodmapr.com
>
> > > Users just cannot login but instead are provided with a PIN
>
> > > On Jun 9, 11:37 pm, Keith Hanson  wrote:
> > >> I'm actually not using an oauth callback parameter and am getting  
> > >> this
> > >> behavior.
>
> > >> I'm running on Sinatra at the moment, but have implemented my login
> > >> routine by pretty much copy/pasting the Rails tutorial in the API
> > >> Wiki.
>
> > >> I'm using the gem OAuth 0.3.5 for redirecting and what-not.
>
> > >> I did take a look at the redirect url, though, and didn't see any
> > >> oauth_callback params set. It sounds as if they shouldn't be there
> > >> anyways, correct?
>
> > >> On Jun 9, 5:28 pm, Elliott Kember  wrote:
>
> > >>> Sorry - having said that, I've removed the oauth_callback parameter
> > >>> and the behaviour is still persisting - and it also doesn't save the
> > >>> authentication so I have to hit Allow every time.
>
> > >>> On Jun 9, 11:21 pm, Elliott Kember  wrote:
>
> >  Hey Matt,
>
> >  Yep, I'm passing oauth_callback - and it does look like that's the
> >  problem, because I have another app which doesn't send it, and it's
> >  working fine.
>
> >  Is this by design, or will it be changed back? I don't need it to  
> >  use
> >  the oauth_callback url that I pass, but it'd be good to return to  
> >  the
> >  specified callback URL by default.
>
> >  Thanks,
> >  Elliott
>
> >  On Jun 9, 11:17 pm, Matt Sanford  wrote:
>
> > > Hi there,
>
> > >      Are you by chance passing anything in to the request_token  
> > > call
> > > for the value of oauth_callback? I checked out a few other  
> > > services
> > > and they seemed fine. If you're sending oauth_callback=oob (a.k.a.
> > > "out of band") then the system is forced into the PIN flow. We're
> > > working on docs for all of this now but let me know if that's what
> > > you're sending.
>
> > > — Matt
>
> > > On Jun 9, 2009, at 2:55 PM, Keith Hanson wrote:
>
> > >> Same here, actually, for tweetingtoohard.com (tried to post here
> > >> before but it looks like it got eaten :P)
>
> > >> We've put up a snarky message in the meantime about the  
> > >> blunders :P
> > >> But please do correct us if we have done something incorrect.
>
> > >> -- Keith Hanson
> > >> @big_love
> > >> keith (at) tweetingtoohard.com
>
> > >> On Jun 9, 4:47 pm, Elliott Kember   
> > >> wrote:
> > >>> Hey guys,
>
> > >>> I'm having a few problems with the OAuth API and my browser-
> > >>> based app
> > >>> - it's giving me PIN numbers at the /oauth/authorize page, even
> > >>> though
> > >>> it's set to return to a callback in the OAuth settings - I've
> > >>> rechecked my settings, and the application is definitely set  
> > >>> as a
> > >>> browser app.
>
> > >>> I'm guessing this is something to do with the new PIN-based  
> > >>> desktop
> > >>> app code, just wondering when it'll be fixed - or whether I'm  
> > >>> doing
> > >>> something wrong!
>
> > >>> Thanks,
> > >>> Elliott

[twitter-dev] Re: [twitter-api-announce] OAuth 1.0a changes and PIN-based authentication shipped

Hi all,

 Quick update on this. If you're using the latest OAuth gem  
(v0.3.5 and above) and you don't specify an oauth_callback to the  
get_request_token method it will put "oob" in there for you. The "oob"  
stand for "out of band" and forces the PIN-based flow … probably not  
what you wanted. I'll talk to the gem developer about a fix for this  
but if you're using the gem the fix in the mean time is to pass your  
expected callback into the get_request_token method like so:

consumer.get_request_token(:oauth_callback => "http://yousite/yourpath";)

Thanks;
   — Matt Sanford


On Jun 9, 2009, at 4:23 PM, Doug Williams wrote:

> Today we deployed code that implemented the changes that accompanied  
> the update to the 1.0a OAuth specification. LuckyCal has a great  
> article on the subtle differences that come with the update [1] so  
> please peruse this article if you are getting 401 errors with your  
> implementation.
>
> Callbacks for non-desktop apps are now supported with these rules:
> - When making the call to request_token [4] (server-to-server), you  
> can pass &oauth_callback=[url here]
> - The response from request_token will contain  
> oauth_callback_confirmed=true to confirm we received it.
> - The user will be sent to twitter.com as usual
> - When the user is finished they will be redirected to the URL  
> provided in the first step along with a new parameter,  
> oauth_verifier [1]
> - The call to access_token [5] to exchange the request token for an  
> access token MUST contain the oauth_verifier parameter as sent in  
> the redirect.
> - If you want to use your pre-configured callback, then do not  
> include a oauth_callback parameter.
> - If you want to force the PIN-based solution, send  
> oauth_callback=oob with your request to oauth/authenticate
>
> Additionally, as a couple developers have already noticed, we  
> deployed the code that implemented PINs for desktop apps originally  
> mentioned by Matt. Please review the linked documentation [2] and  
> discussion [5] and let us know what questions you have.
>
> If you find that your browser-based OAuth application is returning a  
> PIN as if it were a desktop app, then remove the oauth_callback=oob  
> parameter from your signature, if it exists.
>
> 1. http://blog.luckycal.com/?p=121
> 2. http://apiwiki.twitter.com/Authentication
> 3. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-oauth-request_token
> 4. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-oauth-access_token
> 5. 
> http://groups.google.com/group/twitter-development-talk/browse_frm/thread/1c48fedf4ae7ed52/7d772dedcc756cbf#7d772dedcc756cbf
>
> Thanks,
> Doug
>
>
> >

[twitter-dev] Re: PIN response in web-based OAuth app

2009-06-09 Thread lebreeze


I managed to get the old behaviour back by modifying the oauth gem to
not set a default oauth_callback (oob)

For some reason the twitter-auth gem is not passing over the
configuration to override the default

I'm too tired to investigate further at the minute but will keep
looking in the morning (GMT)


On Jun 10, 12:16 am, Matt Sanford  wrote:
> Hi there,
>
>      I just checked the tokens generated on several of these services  
> and I see oauth_callback was set to "oob". Doug is working on the docs  
> right now to make it clear how all of this shakes out. The end result  
> is that if you want to use the pre-configured callback url don't send  
> an oauth_callback parameter at all. If you're seeing this error but  
> are not sending the oauth_callback parameter please email me off list  
> with a copy of the URL, headers and body where you make the  
> request_token call so I can try and debug the issue. It doesn't seem  
> to be all apps which is what I would expect in the case of a bug.
>
> Thanks;
>   – Matt Sanford / @mzsanford
>       Twitter Dev
>
> On Jun 9, 2009, at 3:53 PM, lebreeze wrote:
>
>
>
>
>
> > I'm seeing exactly the same behaviour and it just started happening a
> > few hours ago
>
> > App ishttp://moodmapr.com
>
> > Users just cannot login but instead are provided with a PIN
>
> > On Jun 9, 11:37 pm, Keith Hanson  wrote:
> >> I'm actually not using an oauth callback parameter and am getting  
> >> this
> >> behavior.
>
> >> I'm running on Sinatra at the moment, but have implemented my login
> >> routine by pretty much copy/pasting the Rails tutorial in the API
> >> Wiki.
>
> >> I'm using the gem OAuth 0.3.5 for redirecting and what-not.
>
> >> I did take a look at the redirect url, though, and didn't see any
> >> oauth_callback params set. It sounds as if they shouldn't be there
> >> anyways, correct?
>
> >> On Jun 9, 5:28 pm, Elliott Kember  wrote:
>
> >>> Sorry - having said that, I've removed the oauth_callback parameter
> >>> and the behaviour is still persisting - and it also doesn't save the
> >>> authentication so I have to hit Allow every time.
>
> >>> On Jun 9, 11:21 pm, Elliott Kember  wrote:
>
>  Hey Matt,
>
>  Yep, I'm passing oauth_callback - and it does look like that's the
>  problem, because I have another app which doesn't send it, and it's
>  working fine.
>
>  Is this by design, or will it be changed back? I don't need it to  
>  use
>  the oauth_callback url that I pass, but it'd be good to return to  
>  the
>  specified callback URL by default.
>
>  Thanks,
>  Elliott
>
>  On Jun 9, 11:17 pm, Matt Sanford  wrote:
>
> > Hi there,
>
> >      Are you by chance passing anything in to the request_token  
> > call
> > for the value of oauth_callback? I checked out a few other  
> > services
> > and they seemed fine. If you're sending oauth_callback=oob (a.k.a.
> > "out of band") then the system is forced into the PIN flow. We're
> > working on docs for all of this now but let me know if that's what
> > you're sending.
>
> > — Matt
>
> > On Jun 9, 2009, at 2:55 PM, Keith Hanson wrote:
>
> >> Same here, actually, for tweetingtoohard.com (tried to post here
> >> before but it looks like it got eaten :P)
>
> >> We've put up a snarky message in the meantime about the  
> >> blunders :P
> >> But please do correct us if we have done something incorrect.
>
> >> -- Keith Hanson
> >> @big_love
> >> keith (at) tweetingtoohard.com
>
> >> On Jun 9, 4:47 pm, Elliott Kember   
> >> wrote:
> >>> Hey guys,
>
> >>> I'm having a few problems with the OAuth API and my browser-
> >>> based app
> >>> - it's giving me PIN numbers at the /oauth/authorize page, even
> >>> though
> >>> it's set to return to a callback in the OAuth settings - I've
> >>> rechecked my settings, and the application is definitely set  
> >>> as a
> >>> browser app.
>
> >>> I'm guessing this is something to do with the new PIN-based  
> >>> desktop
> >>> app code, just wondering when it'll be fixed - or whether I'm  
> >>> doing
> >>> something wrong!
>
> >>> Thanks,
> >>> Elliott

[twitter-dev] Re: Twitter Application Usage Guidelines, Please Read

2009-06-09 Thread Justyn Howard

I think it depends on what measures the site is taking to promote
responsible use of the applications. Both applications could be used for
good, or bad. I can think of one fairly popular site that is all but
endorses spammy behavior and charges users for access to these spammy tools.
I don¹t want to point fingers, but my point is, there are probably more
abusive apps out there than these two, and it all comes down to how
responsibly the sites are guiding users, and if they have any rules in place
to get rid of those who abuse it.


On 6/9/09 6:28 PM, "Abraham Williams" <4bra...@gmail.com> wrote:

> In briefly checking out Mutuality and Twollo I'm not sure what about them is
> abusive. Mutuality says it lets you rapidly modify who you are following to
> match who is following you and Twollo auto follows accounts it thinks you
> might be interested in. Those are both useful
> tools and if used as intended are just that. I can see Twitter banning an
> individual user for using the services abusively but not the services
> themselves. 
> 
> On Tue, Jun 9, 2009 at 16:43, Brant  wrote:
>> 
>> This message will hopefully get back to the people who run Twitter API
>> development and spam prevention.
>> 
>> I noticed there are quite a few twitter applications that are
>> developed to abuse the service and violate their TOS.  They do not
>> hide what their purpose is, yet these applications remain active.  I
>> contacted twitter.com/delbius   who heads Twitter
>> Spam prevention and
>> she said that they do revoke API access to abusive applications.  But
>> I don't think they are taking an aggressive stance against them.
>> 
>> Abusive Applications:
>> http://www.huitter.com/mutuality/
>> http://www.twollo.com/
>> 
>> The combination of these two applications is for outright abuse of the
>> service.  They have been around for several months and are known
>> applications to abuse the service with.  To make matters worse,
>> Twitter suspends accounts of the people who use these applications
>> rather than targeting the root of the problem, the applications
>> themselves.  (Sound counterproductive? RIAA uses a similar policy by
>> going after end users.)
>> 
>> I propose that applications need to be more closely scrutinized and
>> can even be flagged as abusive by users. Instead of creating
>> algorithms that detect abnormal user behavior, why not detect abnormal
>> application behavior.
>> 
>> Taking a stronger stance against gray area applications could reduce
>> server load on Twitter (giving real applications faster response time)
>> and reduce manpower to deal with spam prevention.
>> 
>> I strongly encourage anyone who develops Twitter applications to send
>> this link around.
>> 
>> Thanks for reading,
>> Brant
>> twitter.com/BrantTedeschi 
> 
>

[twitter-dev] Re: PIN response in web-based OAuth app

2009-06-09 Thread jotto


I also do not use oauth_callback and this is happening to me as well.

I have emailed a...@twitter.com and Doug Williams responded.

On Jun 9, 5:17 pm, Matt Sanford  wrote:
> Hi there,
>
>      Are you by chance passing anything in to the request_token call  
> for the value of oauth_callback? I checked out a few other services  
> and they seemed fine. If you're sending oauth_callback=oob (a.k.a.  
> "out of band") then the system is forced into the PIN flow. We're  
> working on docs for all of this now but let me know if that's what  
> you're sending.
>
> — Matt
>
> On Jun 9, 2009, at 2:55 PM, Keith Hanson wrote:
>
>
>
> > Same here, actually, for tweetingtoohard.com (tried to post here
> > before but it looks like it got eaten :P)
>
> > We've put up a snarky message in the meantime about the blunders :P
> > But please do correct us if we have done something incorrect.
>
> > -- Keith Hanson
> > @big_love
> > keith (at) tweetingtoohard.com
>
> > On Jun 9, 4:47 pm, Elliott Kember  wrote:
> >> Hey guys,
>
> >> I'm having a few problems with the OAuth API and my browser-based app
> >> - it's giving me PIN numbers at the /oauth/authorize page, even  
> >> though
> >> it's set to return to a callback in the OAuth settings - I've
> >> rechecked my settings, and the application is definitely set as a
> >> browser app.
>
> >> I'm guessing this is something to do with the new PIN-based desktop
> >> app code, just wondering when it'll be fixed - or whether I'm doing
> >> something wrong!
>
> >> Thanks,
> >> Elliott

[twitter-dev] Re: Purposed method: friendships/show

2009-06-09 Thread jim.renkel


It seems from the examples, but not explicitly stated anywhere, that
the values of the following and followed_by items are booleans,
implying that a user either is or is not following another user.

While at first blush that seems true, I think in reality the situation
is a little more complicated, especially if you consider protected
users.

I would propose that these items be enumerations, with the following
values and meanings:
- "yes": user A, say, is following user B;
- "no": user A is not following user B, has not requested the
relationship, and is not blocked from doing so;
- "pending": user A has requested to follow (protected) user B, but B
has not yet accepted, rejected, or blocked the request; and
- "blocked": user A requested to follow (protected) user B, but B
blocked the request.

What I'm looking for here is parity, if you will, between the data and
facilities that are available to the twitter.com web site and to API
users. This is one place where there was not parity, and we have the
opportunity to now get it.

Comments expected, welcome, and appreciated.

Jim Renkel

On Jun 9, 1:13 pm, Damon Clinkscales  wrote:
> If you're going to redefine the way that follow information is
> returned, I believe that it should include the effect of "protected"
> accounts on both sides of the follow equation.
>
> Thanks,
> -damon
> --http://twitter.com/damon
>
> On Tue, Jun 9, 2009 at 10:52 AM, Marcel Molina wrote:
> > Thanks for the suggestion Chad.
> > What do others think of
> > {"relationship": {
> >  "source": {
> >    "id": 123,
> >    "screen_name": "bob",
> >    "notifications": false },
>
> >  "target": {
> >    "id": 456,
> >    "screen_name": "jack",
> >    "notifications": null },
>
> >  "source_follows_target": true,
> >  "source_followed_by_target": false
> > }
> > }
> > versus
>
> > {"relationship": {
>
> > "source": {
>
> > "id": 123,
>
> > "screen_name": "bob",
>
> > "following": true,
>
> > "followed_by": false,
>
> > "notifications_enabled": false },
>
> > "target": {
>
> > "id": 456,
>
> > "screen_name": "jack",
>
> > "following": false,
>
> > "followed_by": true,
>
> > "notifications_enabled": null }
>
> > }
>
> > }

[twitter-dev] Re: PIN response in web-based OAuth app

2009-06-09 Thread Levent Ali


I have made little to no changes and this behaviour just started
happening this evening

Try logging in at http://moodmapr.com to see what happens

I have commented out all the lines of code that pass 'oauth_callback'
in the url on my development environment and it doesn't seem to make a
difference

https://twitter.com/oauth/authorize?oauth_token=TOKEN
or as it used to be (and is in production)
https://twitter.com/oauth/authorize?oauth_token=
TOKEN&oauth_callback=http%3A%2F%2Fmoodmapr.local%2Foauth_callback

My app is a ruby app (rails) using the twitter-auth gem (0.1.21) and
oauth (0.3.5)

Again everything was perfect until a few hours ago was seems to
coincide with everyone else having this issue



On Wed, Jun 10, 2009 at 12:16 AM, Matt Sanford wrote:
>
> Hi there,
>
>    I just checked the tokens generated on several of these services and I
> see oauth_callback was set to "oob". Doug is working on the docs right now
> to make it clear how all of this shakes out. The end result is that if you
> want to use the pre-configured callback url don't send an oauth_callback
> parameter at all. If you're seeing this error but are not sending the
> oauth_callback parameter please email me off list with a copy of the URL,
> headers and body where you make the request_token call so I can try and
> debug the issue. It doesn't seem to be all apps which is what I would expect
> in the case of a bug.
>
> Thanks;
>  – Matt Sanford / @mzsanford
>     Twitter Dev
>
> On Jun 9, 2009, at 3:53 PM, lebreeze wrote:
>
>>
>> I'm seeing exactly the same behaviour and it just started happening a
>> few hours ago
>>
>> App is http://moodmapr.com
>>
>> Users just cannot login but instead are provided with a PIN
>>
>>
>>
>> On Jun 9, 11:37 pm, Keith Hanson  wrote:
>>>
>>> I'm actually not using an oauth callback parameter and am getting this
>>> behavior.
>>>
>>> I'm running on Sinatra at the moment, but have implemented my login
>>> routine by pretty much copy/pasting the Rails tutorial in the API
>>> Wiki.
>>>
>>> I'm using the gem OAuth 0.3.5 for redirecting and what-not.
>>>
>>> I did take a look at the redirect url, though, and didn't see any
>>> oauth_callback params set. It sounds as if they shouldn't be there
>>> anyways, correct?
>>>
>>> On Jun 9, 5:28 pm, Elliott Kember  wrote:
>>>
>>>
>>>
 Sorry - having said that, I've removed the oauth_callback parameter
 and the behaviour is still persisting - and it also doesn't save the
 authentication so I have to hit Allow every time.
>>>
 On Jun 9, 11:21 pm, Elliott Kember  wrote:
>>>
> Hey Matt,
>>>
> Yep, I'm passing oauth_callback - and it does look like that's the
> problem, because I have another app which doesn't send it, and it's
> working fine.
>>>
> Is this by design, or will it be changed back? I don't need it to use
> the oauth_callback url that I pass, but it'd be good to return to the
> specified callback URL by default.
>>>
> Thanks,
> Elliott
>>>
> On Jun 9, 11:17 pm, Matt Sanford  wrote:
>>>
>> Hi there,
>>>
>>     Are you by chance passing anything in to the request_token call
>> for the value of oauth_callback? I checked out a few other services
>> and they seemed fine. If you're sending oauth_callback=oob (a.k.a.
>> "out of band") then the system is forced into the PIN flow. We're
>> working on docs for all of this now but let me know if that's what
>> you're sending.
>>>
>> — Matt
>>>
>> On Jun 9, 2009, at 2:55 PM, Keith Hanson wrote:
>>>
>>> Same here, actually, for tweetingtoohard.com (tried to post here
>>> before but it looks like it got eaten :P)
>>>
>>> We've put up a snarky message in the meantime about the blunders :P
>>> But please do correct us if we have done something incorrect.
>>>
>>> -- Keith Hanson
>>> @big_love
>>> keith (at) tweetingtoohard.com
>>>
>>> On Jun 9, 4:47 pm, Elliott Kember  wrote:

 Hey guys,
>>>
 I'm having a few problems with the OAuth API and my browser-based
 app
 - it's giving me PIN numbers at the /oauth/authorize page, even
 though
 it's set to return to a callback in the OAuth settings - I've
 rechecked my settings, and the application is definitely set as a
 browser app.
>>>
 I'm guessing this is something to do with the new PIN-based desktop
 app code, just wondering when it'll be fixed - or whether I'm doing
 something wrong!
>>>
 Thanks,
 Elliott
>
>

[twitter-dev] Re: PIN response in web-based OAuth app


Huzzah!

It looks like the OAuth gem, when not given the parameter
oauth_callback, automatically passes oob, FTL! :P

So... in our case, we simply did this:
consumer = OAuth::Consumer.new("TOKENZ", "SECRETZ", { :site=>"http://
twitter.com" })
consumer.get_request_token(:oauth_callback => "http://
tweetingtoohard.com/auth_success")

And now things are looking like they ought to :)

Hope that helps anyone else who may be using the OAuth gem with
Ruby :P

--Keith

On Jun 9, 6:16 pm, Matt Sanford  wrote:
> Hi there,
>
>      I just checked the tokens generated on several of these services  
> and I see oauth_callback was set to "oob". Doug is working on the docs  
> right now to make it clear how all of this shakes out. The end result  
> is that if you want to use the pre-configured callback url don't send  
> an oauth_callback parameter at all. If you're seeing this error but  
> are not sending the oauth_callback parameter please email me off list  
> with a copy of the URL, headers and body where you make the  
> request_token call so I can try and debug the issue. It doesn't seem  
> to be all apps which is what I would expect in the case of a bug.
>
> Thanks;
>   – Matt Sanford / @mzsanford
>       Twitter Dev
>
> On Jun 9, 2009, at 3:53 PM, lebreeze wrote:
>
>
>
> > I'm seeing exactly the same behaviour and it just started happening a
> > few hours ago
>
> > App ishttp://moodmapr.com
>
> > Users just cannot login but instead are provided with a PIN
>
> > On Jun 9, 11:37 pm, Keith Hanson  wrote:
> >> I'm actually not using an oauth callback parameter and am getting  
> >> this
> >> behavior.
>
> >> I'm running on Sinatra at the moment, but have implemented my login
> >> routine by pretty much copy/pasting the Rails tutorial in the API
> >> Wiki.
>
> >> I'm using the gem OAuth 0.3.5 for redirecting and what-not.
>
> >> I did take a look at the redirect url, though, and didn't see any
> >> oauth_callback params set. It sounds as if they shouldn't be there
> >> anyways, correct?
>
> >> On Jun 9, 5:28 pm, Elliott Kember  wrote:
>
> >>> Sorry - having said that, I've removed the oauth_callback parameter
> >>> and the behaviour is still persisting - and it also doesn't save the
> >>> authentication so I have to hit Allow every time.
>
> >>> On Jun 9, 11:21 pm, Elliott Kember  wrote:
>
>  Hey Matt,
>
>  Yep, I'm passing oauth_callback - and it does look like that's the
>  problem, because I have another app which doesn't send it, and it's
>  working fine.
>
>  Is this by design, or will it be changed back? I don't need it to  
>  use
>  the oauth_callback url that I pass, but it'd be good to return to  
>  the
>  specified callback URL by default.
>
>  Thanks,
>  Elliott
>
>  On Jun 9, 11:17 pm, Matt Sanford  wrote:
>
> > Hi there,
>
> >      Are you by chance passing anything in to the request_token  
> > call
> > for the value of oauth_callback? I checked out a few other  
> > services
> > and they seemed fine. If you're sending oauth_callback=oob (a.k.a.
> > "out of band") then the system is forced into the PIN flow. We're
> > working on docs for all of this now but let me know if that's what
> > you're sending.
>
> > — Matt
>
> > On Jun 9, 2009, at 2:55 PM, Keith Hanson wrote:
>
> >> Same here, actually, for tweetingtoohard.com (tried to post here
> >> before but it looks like it got eaten :P)
>
> >> We've put up a snarky message in the meantime about the  
> >> blunders :P
> >> But please do correct us if we have done something incorrect.
>
> >> -- Keith Hanson
> >> @big_love
> >> keith (at) tweetingtoohard.com
>
> >> On Jun 9, 4:47 pm, Elliott Kember   
> >> wrote:
> >>> Hey guys,
>
> >>> I'm having a few problems with the OAuth API and my browser-
> >>> based app
> >>> - it's giving me PIN numbers at the /oauth/authorize page, even
> >>> though
> >>> it's set to return to a callback in the OAuth settings - I've
> >>> rechecked my settings, and the application is definitely set  
> >>> as a
> >>> browser app.
>
> >>> I'm guessing this is something to do with the new PIN-based  
> >>> desktop
> >>> app code, just wondering when it'll be fixed - or whether I'm  
> >>> doing
> >>> something wrong!
>
> >>> Thanks,
> >>> Elliott

[twitter-dev] Re: Tweetingtoohard.com being treated as an OAuth Desktop app?

Keith,Let use this thread [1] and this announcement [2] to keep the
discussion from fragmenting.
1.
http://groups.google.com/group/twitter-development-talk/browse_frm/thread/b39aa97f826e7432
2.
http://groups.google.com/group/twitter-development-talk/browse_frm/thread/472500cfe9e7cdb9

Thanks,
Doug



On Tue, Jun 9, 2009 at 2:39 PM, Keith Hanson wrote:

>
> Hello all,
> I am the developer for http://tweetingtoohard.com and have run into
> some.. peculiar issues here.
>
> For some reason, upon being redirected to twitter and allowing our
> application, the user is then given a message to enter a PIN number
> when prompted by Tweetingtoohard.
>
> Frustratingly, I've discovered that this is the behavior for _desktop_
> applications. Upon double and triple checking our settings, I've
> confirmed that Tweetingtoohard.com is indeed using the _browser_
> setting for the application's twitter settings.
>
> None of our users are currently able to log in because of this, which
> means that no one can vote, which ultimately means that our site
> grinds to a halt for those which need to log back in :/
>
> We would greatly appreciate it if this issue were resolved or we were
> at least given some explanation for a work around. It seems as if
> perhaps someone got our wires crossed? :P
>
> Thank you,
> Keith Hanson
> ke...@tweetingtoohard.com
> @big_love
>

[twitter-dev] OAuth 1.0a changes and PIN-based authentication shipped

Today we deployed code that implemented the changes that accompanied the
update to the 1.0a OAuth specification. LuckyCal has a great article on the
subtle differences that come with the update [1] so please peruse this
article if you are getting 401 errors with your implementation.

Callbacks for non-desktop apps are now supported with these rules:
- When making the call to request_token [4] (server-to-server), you can pass
&oauth_callback=[url here]
- The response from request_token will contain oauth_callback_confirmed=true
to confirm we received it.
- The user will be sent to twitter.com as usual
- When the user is finished they will be redirected to the URL provided in
the first step along with a new parameter, oauth_verifier [1]
- The call to access_token [5] to exchange the request token for an access
token MUST contain the oauth_verifier parameter as sent in the redirect.
- If you want to use your pre-configured callback, then do not include a
oauth_callback parameter.
- If you want to force the PIN-based solution, send oauth_callback=oob with
your request to oauth/authenticate

Additionally, as a couple developers have already noticed, we deployed the
code that implemented PINs for desktop apps originally mentioned by Matt.
Please review the linked documentation [2] and discussion [5] and let us
know what questions you have.

If you find that your browser-based OAuth application is returning a PIN as
if it were a desktop app, then remove the oauth_callback=oob parameter from
your signature, if it exists.

1. http://blog.luckycal.com/?p=121
2. http://apiwiki.twitter.com/Authentication
3. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-oauth-request_token
4. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-oauth-access_token
5.
http://groups.google.com/group/twitter-development-talk/browse_frm/thread/1c48fedf4ae7ed52/7d772dedcc756cbf#7d772dedcc756cbf

Thanks,
Doug

[twitter-dev] Re: Twitter Application Usage Guidelines, Please Read

Brant,Thank you for your concern. This is something that bothers us as well.

Moving applications exclusively to OAuth-based authentication will certainly
help in restricting applications that abuse the service. If you find a
service that you think is violating our TOS, please email a...@twitter.com or
send a message to @twitterapi and we can take a look. As you mentioned, Del
is great but she is but one person. We do have an abuse team forming to help
quickly identify which services are violating our TOS. All in all we have a
lot of work to do so please do help where you can.

Cheers,
Doug


On Tue, Jun 9, 2009 at 2:43 PM, Brant  wrote:

>
> This message will hopefully get back to the people who run Twitter API
> development and spam prevention.
>
> I noticed there are quite a few twitter applications that are
> developed to abuse the service and violate their TOS.  They do not
> hide what their purpose is, yet these applications remain active.  I
> contacted twitter.com/delbius who heads Twitter Spam prevention and
> she said that they do revoke API access to abusive applications.  But
> I don't think they are taking an aggressive stance against them.
>
> Abusive Applications:
> http://www.huitter.com/mutuality/
> http://www.twollo.com/
>
> The combination of these two applications is for outright abuse of the
> service.  They have been around for several months and are known
> applications to abuse the service with.  To make matters worse,
> Twitter suspends accounts of the people who use these applications
> rather than targeting the root of the problem, the applications
> themselves.  (Sound counterproductive? RIAA uses a similar policy by
> going after end users.)
>
> I propose that applications need to be more closely scrutinized and
> can even be flagged as abusive by users. Instead of creating
> algorithms that detect abnormal user behavior, why not detect abnormal
> application behavior.
>
> Taking a stronger stance against gray area applications could reduce
> server load on Twitter (giving real applications faster response time)
> and reduce manpower to deal with spam prevention.
>
> I strongly encourage anyone who develops Twitter applications to send
> this link around.
>
> Thanks for reading,
> Brant
> twitter.com/BrantTedeschi
>

[twitter-dev] Re: Twitter Application Usage Guidelines, Please Read

2009-06-09 Thread Abraham Williams

In briefly checking out Mutuality and Twollo I'm not sure what about them is
abusive. Mutuality says it lets you rapidly modify who you are following to
match who is following you and Twollo auto follows accounts it thinks you
might be interested in. Those are both useful
tools and if used as intended are just that. I can see Twitter banning an
individual user for using the services abusively but not the services
themselves.

On Tue, Jun 9, 2009 at 16:43, Brant  wrote:

>
> This message will hopefully get back to the people who run Twitter API
> development and spam prevention.
>
> I noticed there are quite a few twitter applications that are
> developed to abuse the service and violate their TOS.  They do not
> hide what their purpose is, yet these applications remain active.  I
> contacted twitter.com/delbius who heads Twitter Spam prevention and
> she said that they do revoke API access to abusive applications.  But
> I don't think they are taking an aggressive stance against them.
>
> Abusive Applications:
> http://www.huitter.com/mutuality/
> http://www.twollo.com/
>
> The combination of these two applications is for outright abuse of the
> service.  They have been around for several months and are known
> applications to abuse the service with.  To make matters worse,
> Twitter suspends accounts of the people who use these applications
> rather than targeting the root of the problem, the applications
> themselves.  (Sound counterproductive? RIAA uses a similar policy by
> going after end users.)
>
> I propose that applications need to be more closely scrutinized and
> can even be flagged as abusive by users. Instead of creating
> algorithms that detect abnormal user behavior, why not detect abnormal
> application behavior.
>
> Taking a stronger stance against gray area applications could reduce
> server load on Twitter (giving real applications faster response time)
> and reduce manpower to deal with spam prevention.
>
> I strongly encourage anyone who develops Twitter applications to send
> this link around.
>
> Thanks for reading,
> Brant
> twitter.com/BrantTedeschi
>



-- 
Abraham Williams | Community | http://web608.org
Hacker | http://abrah.am | http://twitter.com/abraham
Project | http://fireeagle.labs.poseurtech.com
This email is: [ ] blogable [x] ask first [ ] private.

[twitter-dev] Re: PIN response in web-based OAuth app



Hi there,

I just checked the tokens generated on several of these services  
and I see oauth_callback was set to "oob". Doug is working on the docs  
right now to make it clear how all of this shakes out. The end result  
is that if you want to use the pre-configured callback url don't send  
an oauth_callback parameter at all. If you're seeing this error but  
are not sending the oauth_callback parameter please email me off list  
with a copy of the URL, headers and body where you make the  
request_token call so I can try and debug the issue. It doesn't seem  
to be all apps which is what I would expect in the case of a bug.


Thanks;
 – Matt Sanford / @mzsanford
 Twitter Dev

On Jun 9, 2009, at 3:53 PM, lebreeze wrote:



I'm seeing exactly the same behaviour and it just started happening a
few hours ago

App is http://moodmapr.com

Users just cannot login but instead are provided with a PIN



On Jun 9, 11:37 pm, Keith Hanson  wrote:
I'm actually not using an oauth callback parameter and am getting  
this

behavior.

I'm running on Sinatra at the moment, but have implemented my login
routine by pretty much copy/pasting the Rails tutorial in the API
Wiki.

I'm using the gem OAuth 0.3.5 for redirecting and what-not.

I did take a look at the redirect url, though, and didn't see any
oauth_callback params set. It sounds as if they shouldn't be there
anyways, correct?

On Jun 9, 5:28 pm, Elliott Kember  wrote:




Sorry - having said that, I've removed the oauth_callback parameter
and the behaviour is still persisting - and it also doesn't save the
authentication so I have to hit Allow every time.



On Jun 9, 11:21 pm, Elliott Kember  wrote:



Hey Matt,



Yep, I'm passing oauth_callback - and it does look like that's the
problem, because I have another app which doesn't send it, and it's
working fine.


Is this by design, or will it be changed back? I don't need it to  
use
the oauth_callback url that I pass, but it'd be good to return to  
the

specified callback URL by default.



Thanks,
Elliott



On Jun 9, 11:17 pm, Matt Sanford  wrote:



Hi there,


 Are you by chance passing anything in to the request_token  
call
for the value of oauth_callback? I checked out a few other  
services

and they seemed fine. If you're sending oauth_callback=oob (a.k.a.
"out of band") then the system is forced into the PIN flow. We're
working on docs for all of this now but let me know if that's what
you're sending.



— Matt



On Jun 9, 2009, at 2:55 PM, Keith Hanson wrote:



Same here, actually, for tweetingtoohard.com (tried to post here
before but it looks like it got eaten :P)


We've put up a snarky message in the meantime about the  
blunders :P

But please do correct us if we have done something incorrect.



-- Keith Hanson
@big_love
keith (at) tweetingtoohard.com


On Jun 9, 4:47 pm, Elliott Kember   
wrote:

Hey guys,


I'm having a few problems with the OAuth API and my browser- 
based app

- it's giving me PIN numbers at the /oauth/authorize page, even
though
it's set to return to a callback in the OAuth settings - I've
rechecked my settings, and the application is definitely set  
as a

browser app.


I'm guessing this is something to do with the new PIN-based  
desktop
app code, just wondering when it'll be fixed - or whether I'm  
doing

something wrong!



Thanks,
Elliott

[twitter-dev] Re: PIN response in web-based OAuth app



Hi there,

Are you by chance passing anything in to the request_token call  
for the value of oauth_callback? I checked out a few other services  
and they seemed fine. If you're sending oauth_callback=oob (a.k.a.  
"out of band") then the system is forced into the PIN flow. We're  
working on docs for all of this now but let me know if that's what  
you're sending.


— Matt

On Jun 9, 2009, at 2:55 PM, Keith Hanson wrote:



Same here, actually, for tweetingtoohard.com (tried to post here
before but it looks like it got eaten :P)

We've put up a snarky message in the meantime about the blunders :P
But please do correct us if we have done something incorrect.

-- Keith Hanson
@big_love
keith (at) tweetingtoohard.com

On Jun 9, 4:47 pm, Elliott Kember  wrote:

Hey guys,

I'm having a few problems with the OAuth API and my browser-based app
- it's giving me PIN numbers at the /oauth/authorize page, even  
though

it's set to return to a callback in the OAuth settings - I've
rechecked my settings, and the application is definitely set as a
browser app.

I'm guessing this is something to do with the new PIN-based desktop
app code, just wondering when it'll be fixed - or whether I'm doing
something wrong!

Thanks,
Elliott

[twitter-dev] Re: PIN response in web-based OAuth app

2009-06-09 Thread lebreeze


I'm seeing exactly the same behaviour and it just started happening a
few hours ago

App is http://moodmapr.com

Users just cannot login but instead are provided with a PIN



On Jun 9, 11:37 pm, Keith Hanson  wrote:
> I'm actually not using an oauth callback parameter and am getting this
> behavior.
>
> I'm running on Sinatra at the moment, but have implemented my login
> routine by pretty much copy/pasting the Rails tutorial in the API
> Wiki.
>
> I'm using the gem OAuth 0.3.5 for redirecting and what-not.
>
> I did take a look at the redirect url, though, and didn't see any
> oauth_callback params set. It sounds as if they shouldn't be there
> anyways, correct?
>
> On Jun 9, 5:28 pm, Elliott Kember  wrote:
>
>
>
> > Sorry - having said that, I've removed the oauth_callback parameter
> > and the behaviour is still persisting - and it also doesn't save the
> > authentication so I have to hit Allow every time.
>
> > On Jun 9, 11:21 pm, Elliott Kember  wrote:
>
> > > Hey Matt,
>
> > > Yep, I'm passing oauth_callback - and it does look like that's the
> > > problem, because I have another app which doesn't send it, and it's
> > > working fine.
>
> > > Is this by design, or will it be changed back? I don't need it to use
> > > the oauth_callback url that I pass, but it'd be good to return to the
> > > specified callback URL by default.
>
> > > Thanks,
> > > Elliott
>
> > > On Jun 9, 11:17 pm, Matt Sanford  wrote:
>
> > > > Hi there,
>
> > > >      Are you by chance passing anything in to the request_token call  
> > > > for the value of oauth_callback? I checked out a few other services  
> > > > and they seemed fine. If you're sending oauth_callback=oob (a.k.a.  
> > > > "out of band") then the system is forced into the PIN flow. We're  
> > > > working on docs for all of this now but let me know if that's what  
> > > > you're sending.
>
> > > > — Matt
>
> > > > On Jun 9, 2009, at 2:55 PM, Keith Hanson wrote:
>
> > > > > Same here, actually, for tweetingtoohard.com (tried to post here
> > > > > before but it looks like it got eaten :P)
>
> > > > > We've put up a snarky message in the meantime about the blunders :P
> > > > > But please do correct us if we have done something incorrect.
>
> > > > > -- Keith Hanson
> > > > > @big_love
> > > > > keith (at) tweetingtoohard.com
>
> > > > > On Jun 9, 4:47 pm, Elliott Kember  wrote:
> > > > >> Hey guys,
>
> > > > >> I'm having a few problems with the OAuth API and my browser-based app
> > > > >> - it's giving me PIN numbers at the /oauth/authorize page, even  
> > > > >> though
> > > > >> it's set to return to a callback in the OAuth settings - I've
> > > > >> rechecked my settings, and the application is definitely set as a
> > > > >> browser app.
>
> > > > >> I'm guessing this is something to do with the new PIN-based desktop
> > > > >> app code, just wondering when it'll be fixed - or whether I'm doing
> > > > >> something wrong!
>
> > > > >> Thanks,
> > > > >> Elliott

[twitter-dev] Re: PIN response in web-based OAuth app


I'm actually not using an oauth callback parameter and am getting this
behavior.

I'm running on Sinatra at the moment, but have implemented my login
routine by pretty much copy/pasting the Rails tutorial in the API
Wiki.

I'm using the gem OAuth 0.3.5 for redirecting and what-not.

I did take a look at the redirect url, though, and didn't see any
oauth_callback params set. It sounds as if they shouldn't be there
anyways, correct?

On Jun 9, 5:28 pm, Elliott Kember  wrote:
> Sorry - having said that, I've removed the oauth_callback parameter
> and the behaviour is still persisting - and it also doesn't save the
> authentication so I have to hit Allow every time.
>
> On Jun 9, 11:21 pm, Elliott Kember  wrote:
>
> > Hey Matt,
>
> > Yep, I'm passing oauth_callback - and it does look like that's the
> > problem, because I have another app which doesn't send it, and it's
> > working fine.
>
> > Is this by design, or will it be changed back? I don't need it to use
> > the oauth_callback url that I pass, but it'd be good to return to the
> > specified callback URL by default.
>
> > Thanks,
> > Elliott
>
> > On Jun 9, 11:17 pm, Matt Sanford  wrote:
>
> > > Hi there,
>
> > >      Are you by chance passing anything in to the request_token call  
> > > for the value of oauth_callback? I checked out a few other services  
> > > and they seemed fine. If you're sending oauth_callback=oob (a.k.a.  
> > > "out of band") then the system is forced into the PIN flow. We're  
> > > working on docs for all of this now but let me know if that's what  
> > > you're sending.
>
> > > — Matt
>
> > > On Jun 9, 2009, at 2:55 PM, Keith Hanson wrote:
>
> > > > Same here, actually, for tweetingtoohard.com (tried to post here
> > > > before but it looks like it got eaten :P)
>
> > > > We've put up a snarky message in the meantime about the blunders :P
> > > > But please do correct us if we have done something incorrect.
>
> > > > -- Keith Hanson
> > > > @big_love
> > > > keith (at) tweetingtoohard.com
>
> > > > On Jun 9, 4:47 pm, Elliott Kember  wrote:
> > > >> Hey guys,
>
> > > >> I'm having a few problems with the OAuth API and my browser-based app
> > > >> - it's giving me PIN numbers at the /oauth/authorize page, even  
> > > >> though
> > > >> it's set to return to a callback in the OAuth settings - I've
> > > >> rechecked my settings, and the application is definitely set as a
> > > >> browser app.
>
> > > >> I'm guessing this is something to do with the new PIN-based desktop
> > > >> app code, just wondering when it'll be fixed - or whether I'm doing
> > > >> something wrong!
>
> > > >> Thanks,
> > > >> Elliott

[twitter-dev] Re: PIN response in web-based OAuth app


Sorry - having said that, I've removed the oauth_callback parameter
and the behaviour is still persisting - and it also doesn't save the
authentication so I have to hit Allow every time.

On Jun 9, 11:21 pm, Elliott Kember  wrote:
> Hey Matt,
>
> Yep, I'm passing oauth_callback - and it does look like that's the
> problem, because I have another app which doesn't send it, and it's
> working fine.
>
> Is this by design, or will it be changed back? I don't need it to use
> the oauth_callback url that I pass, but it'd be good to return to the
> specified callback URL by default.
>
> Thanks,
> Elliott
>
> On Jun 9, 11:17 pm, Matt Sanford  wrote:
>
>
>
> > Hi there,
>
> >      Are you by chance passing anything in to the request_token call  
> > for the value of oauth_callback? I checked out a few other services  
> > and they seemed fine. If you're sending oauth_callback=oob (a.k.a.  
> > "out of band") then the system is forced into the PIN flow. We're  
> > working on docs for all of this now but let me know if that's what  
> > you're sending.
>
> > — Matt
>
> > On Jun 9, 2009, at 2:55 PM, Keith Hanson wrote:
>
> > > Same here, actually, for tweetingtoohard.com (tried to post here
> > > before but it looks like it got eaten :P)
>
> > > We've put up a snarky message in the meantime about the blunders :P
> > > But please do correct us if we have done something incorrect.
>
> > > -- Keith Hanson
> > > @big_love
> > > keith (at) tweetingtoohard.com
>
> > > On Jun 9, 4:47 pm, Elliott Kember  wrote:
> > >> Hey guys,
>
> > >> I'm having a few problems with the OAuth API and my browser-based app
> > >> - it's giving me PIN numbers at the /oauth/authorize page, even  
> > >> though
> > >> it's set to return to a callback in the OAuth settings - I've
> > >> rechecked my settings, and the application is definitely set as a
> > >> browser app.
>
> > >> I'm guessing this is something to do with the new PIN-based desktop
> > >> app code, just wondering when it'll be fixed - or whether I'm doing
> > >> something wrong!
>
> > >> Thanks,
> > >> Elliott

[twitter-dev] Re: PIN response in web-based OAuth app


Hey Matt,

Yep, I'm passing oauth_callback - and it does look like that's the
problem, because I have another app which doesn't send it, and it's
working fine.

Is this by design, or will it be changed back? I don't need it to use
the oauth_callback url that I pass, but it'd be good to return to the
specified callback URL by default.

Thanks,
Elliott

On Jun 9, 11:17 pm, Matt Sanford  wrote:
> Hi there,
>
>      Are you by chance passing anything in to the request_token call  
> for the value of oauth_callback? I checked out a few other services  
> and they seemed fine. If you're sending oauth_callback=oob (a.k.a.  
> "out of band") then the system is forced into the PIN flow. We're  
> working on docs for all of this now but let me know if that's what  
> you're sending.
>
> — Matt
>
> On Jun 9, 2009, at 2:55 PM, Keith Hanson wrote:
>
>
>
>
>
> > Same here, actually, for tweetingtoohard.com (tried to post here
> > before but it looks like it got eaten :P)
>
> > We've put up a snarky message in the meantime about the blunders :P
> > But please do correct us if we have done something incorrect.
>
> > -- Keith Hanson
> > @big_love
> > keith (at) tweetingtoohard.com
>
> > On Jun 9, 4:47 pm, Elliott Kember  wrote:
> >> Hey guys,
>
> >> I'm having a few problems with the OAuth API and my browser-based app
> >> - it's giving me PIN numbers at the /oauth/authorize page, even  
> >> though
> >> it's set to return to a callback in the OAuth settings - I've
> >> rechecked my settings, and the application is definitely set as a
> >> browser app.
>
> >> I'm guessing this is something to do with the new PIN-based desktop
> >> app code, just wondering when it'll be fixed - or whether I'm doing
> >> something wrong!
>
> >> Thanks,
> >> Elliott

[twitter-dev] Twitter Application Usage Guidelines, Please Read

2009-06-09 Thread Brant


This message will hopefully get back to the people who run Twitter API
development and spam prevention.

I noticed there are quite a few twitter applications that are
developed to abuse the service and violate their TOS.  They do not
hide what their purpose is, yet these applications remain active.  I
contacted twitter.com/delbius who heads Twitter Spam prevention and
she said that they do revoke API access to abusive applications.  But
I don't think they are taking an aggressive stance against them.

Abusive Applications:
http://www.huitter.com/mutuality/
http://www.twollo.com/

The combination of these two applications is for outright abuse of the
service.  They have been around for several months and are known
applications to abuse the service with.  To make matters worse,
Twitter suspends accounts of the people who use these applications
rather than targeting the root of the problem, the applications
themselves.  (Sound counterproductive? RIAA uses a similar policy by
going after end users.)

I propose that applications need to be more closely scrutinized and
can even be flagged as abusive by users. Instead of creating
algorithms that detect abnormal user behavior, why not detect abnormal
application behavior.

Taking a stronger stance against gray area applications could reduce
server load on Twitter (giving real applications faster response time)
and reduce manpower to deal with spam prevention.

I strongly encourage anyone who develops Twitter applications to send
this link around.

Thanks for reading,
Brant
twitter.com/BrantTedeschi

[twitter-dev] Tweetingtoohard.com being treated as an OAuth Desktop app?


Hello all,
I am the developer for http://tweetingtoohard.com and have run into
some.. peculiar issues here.

For some reason, upon being redirected to twitter and allowing our
application, the user is then given a message to enter a PIN number
when prompted by Tweetingtoohard.

Frustratingly, I've discovered that this is the behavior for _desktop_
applications. Upon double and triple checking our settings, I've
confirmed that Tweetingtoohard.com is indeed using the _browser_
setting for the application's twitter settings.

None of our users are currently able to log in because of this, which
means that no one can vote, which ultimately means that our site
grinds to a halt for those which need to log back in :/

We would greatly appreciate it if this issue were resolved or we were
at least given some explanation for a work around. It seems as if
perhaps someone got our wires crossed? :P

Thank you,
Keith Hanson
ke...@tweetingtoohard.com
@big_love

[twitter-dev] PIN response in web-based OAuth app


Hey guys,

I'm having a few problems with the OAuth API and my browser-based app
- it's giving me PIN numbers at the /oauth/authorize page, even though
it's set to return to a callback in the OAuth settings - I've
rechecked my settings, and the application is definitely set as a
browser app.

I'm guessing this is something to do with the new PIN-based desktop
app code, just wondering when it'll be fixed - or whether I'm doing
something wrong!

Thanks,
Elliott

[twitter-dev] Re: PIN response in web-based OAuth app


Same here, actually, for tweetingtoohard.com (tried to post here
before but it looks like it got eaten :P)

We've put up a snarky message in the meantime about the blunders :P
But please do correct us if we have done something incorrect.

-- Keith Hanson
@big_love
keith (at) tweetingtoohard.com

On Jun 9, 4:47 pm, Elliott Kember  wrote:
> Hey guys,
>
> I'm having a few problems with the OAuth API and my browser-based app
> - it's giving me PIN numbers at the /oauth/authorize page, even though
> it's set to return to a callback in the OAuth settings - I've
> rechecked my settings, and the application is definitely set as a
> browser app.
>
> I'm guessing this is something to do with the new PIN-based desktop
> app code, just wondering when it'll be fixed - or whether I'm doing
> something wrong!
>
> Thanks,
> Elliott

[twitter-dev] Re: Revoke/Destroy Access Method?

2009-06-09 Thread fastest963


alright thanks!

On Jun 8, 8:25 pm, Abraham Williams <4bra...@gmail.com> wrote:
> I would just say delete the access tokens from your database and call it
> good. If they care that much they can figure the connections page on their
> own.
>
>
>
>
>
> On Mon, Jun 8, 2009 at 18:21, fastest963  wrote:
>
> > Sorry about the late reply...
>
> > I mean if the user revokes access from my site, not knowing that he/
> > she should go through yours?
> > Or should I just direct users to the "connections" page to revoke
> > access directly from your site?
>
> > On Jun 5, 8:22 am, Abraham Williams <4bra...@gmail.com> wrote:
> > > Why would you need to destroy the access keys? They stop working once the
> > > user revokes access. I guess you could delete them from your database.
>
> > > On Fri, Jun 5, 2009 at 06:44, fastest963  wrote:
>
> > > > So user deletes his/her twitter access from my site, as in she says I
> > > > don't want to give this app access anymore so on my site she clicks
> > > > "remove twitter access/account".
> > > > Is there a method I can call to destroy the access keys I received and
> > > > automatically revoke access to my application? I know for Facebook, it
> > > > is a rule, you MUST destroy the keys and disconnect the user if they
> > > > cancel access, but I don't see this anywhere on Twitters
> > > > documentation.
>
> > > > Thanks,
> > > > @fastest963
>
> > > --
> > > Abraham Williams |http://the.hackerconundrum.com
> > > Hacker |http://abrah.am|http://twitter.com/abraham
> > > Project |http://fireeagle.labs.poseurtech.com
> > > This email is: [ ] blogable [x] ask first [ ] private.
>
> --
> Abraham Williams | Community |http://web608.org
> Hacker |http://abrah.am|http://twitter.com/abraham
> Project |http://fireeagle.labs.poseurtech.com
> This email is: [ ] blogable [x] ask first [ ] private.

[twitter-dev] issue 646

2009-06-09 Thread Jonas


I'm curious why there have been no progress updates regarding issue
646.  Can anyone speak to the status of this problem.

See http://code.google.com/p/twitter-api/issues/detail?id=646

[twitter-dev] Re: Twitter Logo on Facebook

Can you please email a...@twitter.com regarding this request. This is best
handled off-list.
Thanks,
Doug

On Tue, Jun 9, 2009 at 11:39 AM, Chuck Lynch  wrote:

>
> I have created an image that I am using to link my companies facebook
> page to its twitter page. The image has my companies logo and the
> "twitter" blue lettering logo and says "Follow Us!" Is this allowed by
> Twitter, or must I contact them for permission? I can provide the
> image upon request.
>

[twitter-dev] Twitter Logo on Facebook

2009-06-09 Thread Chuck Lynch


I have created an image that I am using to link my companies facebook
page to its twitter page. The image has my companies logo and the
"twitter" blue lettering logo and says "Follow Us!" Is this allowed by
Twitter, or must I contact them for permission? I can provide the
image upon request.

[twitter-dev] Re: Image upload added to PHP OAuth library - need testers

2009-06-09 Thread jmathai


Link would be nice: http://github.com/jmathai/twitter-async/tree/multipart

On Jun 9, 1:02 pm, jmathai  wrote:
> I added multipart image upload support to EpiTwitter.  It's in a
> multipart branch at the moment and am looking for others to test it
> out before merging into master.  Let me know if you manage to test it
> out and whether or not it works for you.
>
> I haven't updated any docs but here is the usage.
>
> $twitterObj = new EpiTwitter($consumerKey, $consumerSecret, $token,
> $tokenSecret);
> $resp = $twitterObj->post_accountUpdate_profile_image(array('@image'
> => '@/absolute/path/to/file'));
> echo $resp->responseText;

[twitter-dev] Image upload added to PHP OAuth library - need testers

2009-06-09 Thread jmathai


I added multipart image upload support to EpiTwitter.  It's in a
multipart branch at the moment and am looking for others to test it
out before merging into master.  Let me know if you manage to test it
out and whether or not it works for you.

I haven't updated any docs but here is the usage.

$twitterObj = new EpiTwitter($consumerKey, $consumerSecret, $token,
$tokenSecret);
$resp = $twitterObj->post_accountUpdate_profile_image(array('@image'
=> '@/absolute/path/to/file'));
echo $resp->responseText;

[twitter-dev] How to get listed on search apps page

2009-06-09 Thread Adam Loving


>From the bottom of the search page, there is a link to a list of apps.

http://search.twitter.com/apps

I would like my app (http://twibes.com) to be listed here. It uses the
search API to aggregate tweets.

There is a link at the bottom of the page to help.twitter.com with the
text "Are you using our Search API? Let us know what you're up to!".
However, I cannot find any way to open a ZenDesk support ticket
except by going to http://getsatisfaction.com/twitter.

In any case, please add my app!

Thanks,
Adam

[twitter-dev] Re: Purposed method: friendships/show

2009-06-09 Thread Damon Clinkscales


If you're going to redefine the way that follow information is
returned, I believe that it should include the effect of "protected"
accounts on both sides of the follow equation.

Thanks,
-damon
--
http://twitter.com/damon

On Tue, Jun 9, 2009 at 10:52 AM, Marcel Molina wrote:
> Thanks for the suggestion Chad.
> What do others think of
> {"relationship": {
>  "source": {
>    "id": 123,
>    "screen_name": "bob",
>    "notifications": false },
>
>  "target": {
>    "id": 456,
>    "screen_name": "jack",
>    "notifications": null },
>
>  "source_follows_target": true,
>  "source_followed_by_target": false
> }
> }
> versus
>
> {"relationship": {
>
> "source": {
>
> "id": 123,
>
> "screen_name": "bob",
>
> "following": true,
>
> "followed_by": false,
>
> "notifications_enabled": false },
>
> "target": {
>
> "id": 456,
>
> "screen_name": "jack",
>
> "following": false,
>
> "followed_by": true,
>
> "notifications_enabled": null }
>
> }
>
> }

[twitter-dev] Re: Purposed method: friendships/show

Thanks for the suggestion Chad.
What do others think of

{"relationship": {
 "source": {
   "id": 123,
   "screen_name": "bob",
   "notifications": false },

 "target": {
   "id": 456,
   "screen_name": "jack",
   "notifications": null },

 "source_follows_target": true,
 "source_followed_by_target": false
}
}

versus

{"relationship": {

"source": {

"id": 123,

"screen_name": "bob",

"following": true,

"followed_by": false,

"notifications_enabled": false },

"target": {

"id": 456,

"screen_name": "jack",

"following": false,

"followed_by": true,

"notifications_enabled": null }

}

}



On Tue, Jun 9, 2009 at 10:41 AM, Chad Etzel  wrote:

>
> Hi Marcel,
>
> Welcome to Twitter, btw (if I'm allowed to say that).
>
> One unambiguous way might be:
>
> {"relationship": {
>  "source": {
>"id": 123,
>"screen_name": "bob",
> "notifications": false },
>
>  "target": {
>"id": 456,
>"screen_name": "jack",
> "notifications": null },
>
>  "source_follows_target": true,
>  "source_followed_by_target": false
> }
> }
>
> This also eliminates redundant data.
>
> Btw, http://twitter.com/@noradio doesn't quite work as a link :)
>
> -Chad
>
> On Tue, Jun 9, 2009 at 1:33 PM, Marcel  Molina  wrote:
> >
> > Hey Chad, thanks for your feedback.
> >
> > Thought experiment: Put aside the currently proposed response body for
> > the moment. How would you unambiguously express the following/followed
> > by relationship?
> >
> > Marcel Molina
> > Twitter API Team
> > http://twitter.com/@noradio
> >
> > On Jun 9, 10:23 am, Chad Etzel  wrote:
> >> Thanks for adding the extra verbiage.
> >>
> >> However, I'm still not clear how to decipher the exact relationship
> >> given the data.  In the example, is Bob following Jack? ...or is Jack
> >> following Bob?
> >>
> >> -Chad
> >>
> >>
> >>
> >> On Tue, Jun 9, 2009 at 1:12 PM, Doug Williams  wrote:
> >> > Thanks, Chad. I've augmented the usage notes section to explain the
> >> > rationale behind the denormalized and redundant data.
> >> > Thanks,
> >> > Doug
> >>
> >> > On Tue, Jun 9, 2009 at 9:47 AM, Chad Etzel 
> wrote:
> >>
> >> >> Taking a look at the json return example:
> >> >> {"relationship": {
> >> >> "source": {
> >> >> "id": 123,
> >> >> "screen_name": "bob",
> >> >> "following": true,
> >> >> "followed_by": false,
> >> >> "notifications": false },
> >>
> >> >> "target": {
> >> >> "id": 456,
> >> >> "screen_name": "jack",
> >> >> "following": false,
> >> >> "followed_by": true,
> >> >> "notifications": null }
> >> >> }
> >> >> }
> >>
> >> >> In the "source" object (i.e. for "bob"), "following" is true.  Does
> >> >> this mean that Bob is following Jack, or vice-versa?
> >>
> >> >> Knowing that, the other 3 following/followed_by value meanings can be
> >> >> properly inferred.  Some clarification on the page would help.
> >>
> >> >> -Chad
> >>
> >> >> On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams 
> wrote:
> >> >> > That makes things difficult. Permissions are now public.
> >> >> > Thanks,
> >> >> > Doug
> >>
> >> >> > On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel 
> wrote:
> >>
> >> >> >> 
> >> >> >> Access Denied
> >>
> >> >> >> You don't have permission to look at Twitter REST API Method:
> >> >> >> friendships
> >> >> >> show.
> >> >> >> 
> >>
> >> >> >> :)
> >> >> >> -Chad
> >>
> >> >> >> On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams 
> >> >> >> wrote:
> >> >> >> > We discussed the need to deprecate the  and
> >> >> >> > 
> >> >> >> > elements [1] a few weeks back. We have begun work on the
> >> >> >> > friendships/show
> >> >> >> > method as mentioned in the notice. The method is slightly out of
> our
> >> >> >> > conventional design, so we are soliciting opinions on its
> fitness for
> >> >> >> > general use-cases. Please peruse the purposed method's
> documentation
> >> >> >> > [2]
> >> >> >> > and
> >> >> >> > let us know what you think.
> >>
> >> >> >> > 1.
> http://groups.google.com/group/twitter-development-talk/browse_frm/th...
> >>
> >> >> >> > 2.
> http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
> >> >> >> > Thanks,
> >> >> >> > Doug
> >
>



-- 
Marcel Molina
Twitter API Team
http://twitter.com/noradio

[twitter-dev] Re: Purposed method: friendships/show


Hi Marcel,

Welcome to Twitter, btw (if I'm allowed to say that).

One unambiguous way might be:

{"relationship": {
  "source": {
"id": 123,
"screen_name": "bob",
"notifications": false },

  "target": {
"id": 456,
"screen_name": "jack",
"notifications": null },

  "source_follows_target": true,
  "source_followed_by_target": false
}
}

This also eliminates redundant data.

Btw, http://twitter.com/@noradio doesn't quite work as a link :)

-Chad

On Tue, Jun 9, 2009 at 1:33 PM, Marcel  Molina  wrote:
>
> Hey Chad, thanks for your feedback.
>
> Thought experiment: Put aside the currently proposed response body for
> the moment. How would you unambiguously express the following/followed
> by relationship?
>
> Marcel Molina
> Twitter API Team
> http://twitter.com/@noradio
>
> On Jun 9, 10:23 am, Chad Etzel  wrote:
>> Thanks for adding the extra verbiage.
>>
>> However, I'm still not clear how to decipher the exact relationship
>> given the data.  In the example, is Bob following Jack? ...or is Jack
>> following Bob?
>>
>> -Chad
>>
>>
>>
>> On Tue, Jun 9, 2009 at 1:12 PM, Doug Williams  wrote:
>> > Thanks, Chad. I've augmented the usage notes section to explain the
>> > rationale behind the denormalized and redundant data.
>> > Thanks,
>> > Doug
>>
>> > On Tue, Jun 9, 2009 at 9:47 AM, Chad Etzel  wrote:
>>
>> >> Taking a look at the json return example:
>> >> {"relationship": {
>> >> "source": {
>> >> "id": 123,
>> >> "screen_name": "bob",
>> >> "following": true,
>> >> "followed_by": false,
>> >> "notifications": false },
>>
>> >> "target": {
>> >> "id": 456,
>> >> "screen_name": "jack",
>> >> "following": false,
>> >> "followed_by": true,
>> >> "notifications": null }
>> >> }
>> >> }
>>
>> >> In the "source" object (i.e. for "bob"), "following" is true.  Does
>> >> this mean that Bob is following Jack, or vice-versa?
>>
>> >> Knowing that, the other 3 following/followed_by value meanings can be
>> >> properly inferred.  Some clarification on the page would help.
>>
>> >> -Chad
>>
>> >> On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams  wrote:
>> >> > That makes things difficult. Permissions are now public.
>> >> > Thanks,
>> >> > Doug
>>
>> >> > On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel  wrote:
>>
>> >> >> 
>> >> >> Access Denied
>>
>> >> >> You don't have permission to look at Twitter REST API Method:
>> >> >> friendships
>> >> >> show.
>> >> >> 
>>
>> >> >> :)
>> >> >> -Chad
>>
>> >> >> On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams 
>> >> >> wrote:
>> >> >> > We discussed the need to deprecate the  and
>> >> >> > 
>> >> >> > elements [1] a few weeks back. We have begun work on the
>> >> >> > friendships/show
>> >> >> > method as mentioned in the notice. The method is slightly out of our
>> >> >> > conventional design, so we are soliciting opinions on its fitness for
>> >> >> > general use-cases. Please peruse the purposed method's documentation
>> >> >> > [2]
>> >> >> > and
>> >> >> > let us know what you think.
>>
>> >> >> > 1. http://groups.google.com/group/twitter-development-talk/browse_frm/th...
>>
>> >> >> > 2. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
>> >> >> > Thanks,
>> >> >> > Doug
>

[twitter-dev] Need more takers for Twitter survey: http://tinyurl.com/lysvah

2009-06-09 Thread Neicole


I need more users to take my Twitter survey. If you've got a moment,
pls take it. (Tweet it, if you want, too) http://tinyurl.com/lysvah,

Conducting an informal survey on Twitter. Actually, anyone can take
it, even non-Twitter users, so feel free to forward in email to anyone
you know who is a Twitter virgin.

I'll post a link to the results when I complete the survey. (I'm the
same one who did the Twitter Developer demographics survey a while
back, which results are available on my site below).

Thanks!
nmc.itdevworks.com

[twitter-dev] Re: Purposed method: friendships/show


Hey Chad, thanks for your feedback.

Thought experiment: Put aside the currently proposed response body for
the moment. How would you unambiguously express the following/followed
by relationship?

Marcel Molina
Twitter API Team
http://twitter.com/@noradio

On Jun 9, 10:23 am, Chad Etzel  wrote:
> Thanks for adding the extra verbiage.
>
> However, I'm still not clear how to decipher the exact relationship
> given the data.  In the example, is Bob following Jack? ...or is Jack
> following Bob?
>
> -Chad
>
>
>
> On Tue, Jun 9, 2009 at 1:12 PM, Doug Williams  wrote:
> > Thanks, Chad. I've augmented the usage notes section to explain the
> > rationale behind the denormalized and redundant data.
> > Thanks,
> > Doug
>
> > On Tue, Jun 9, 2009 at 9:47 AM, Chad Etzel  wrote:
>
> >> Taking a look at the json return example:
> >> {"relationship": {
> >> "source": {
> >> "id": 123,
> >> "screen_name": "bob",
> >> "following": true,
> >> "followed_by": false,
> >> "notifications": false },
>
> >> "target": {
> >> "id": 456,
> >> "screen_name": "jack",
> >> "following": false,
> >> "followed_by": true,
> >> "notifications": null }
> >> }
> >> }
>
> >> In the "source" object (i.e. for "bob"), "following" is true.  Does
> >> this mean that Bob is following Jack, or vice-versa?
>
> >> Knowing that, the other 3 following/followed_by value meanings can be
> >> properly inferred.  Some clarification on the page would help.
>
> >> -Chad
>
> >> On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams  wrote:
> >> > That makes things difficult. Permissions are now public.
> >> > Thanks,
> >> > Doug
>
> >> > On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel  wrote:
>
> >> >> 
> >> >> Access Denied
>
> >> >> You don't have permission to look at Twitter REST API Method:
> >> >> friendships
> >> >> show.
> >> >> 
>
> >> >> :)
> >> >> -Chad
>
> >> >> On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams 
> >> >> wrote:
> >> >> > We discussed the need to deprecate the  and
> >> >> > 
> >> >> > elements [1] a few weeks back. We have begun work on the
> >> >> > friendships/show
> >> >> > method as mentioned in the notice. The method is slightly out of our
> >> >> > conventional design, so we are soliciting opinions on its fitness for
> >> >> > general use-cases. Please peruse the purposed method's documentation
> >> >> > [2]
> >> >> > and
> >> >> > let us know what you think.
>
> >> >> > 1. http://groups.google.com/group/twitter-development-talk/browse_frm/th...
>
> >> >> > 2. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
> >> >> > Thanks,
> >> >> > Doug

[twitter-dev] Re: Purposed method: friendships/show


Thanks for adding the extra verbiage.

However, I'm still not clear how to decipher the exact relationship
given the data.  In the example, is Bob following Jack? ...or is Jack
following Bob?

-Chad

On Tue, Jun 9, 2009 at 1:12 PM, Doug Williams  wrote:
> Thanks, Chad. I've augmented the usage notes section to explain the
> rationale behind the denormalized and redundant data.
> Thanks,
> Doug
>
>
>
> On Tue, Jun 9, 2009 at 9:47 AM, Chad Etzel  wrote:
>>
>> Taking a look at the json return example:
>> {"relationship": {
>> "source": {
>> "id": 123,
>> "screen_name": "bob",
>> "following": true,
>> "followed_by": false,
>> "notifications": false },
>>
>> "target": {
>> "id": 456,
>> "screen_name": "jack",
>> "following": false,
>> "followed_by": true,
>> "notifications": null }
>> }
>> }
>>
>> In the "source" object (i.e. for "bob"), "following" is true.  Does
>> this mean that Bob is following Jack, or vice-versa?
>>
>> Knowing that, the other 3 following/followed_by value meanings can be
>> properly inferred.  Some clarification on the page would help.
>>
>> -Chad
>>
>> On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams  wrote:
>> > That makes things difficult. Permissions are now public.
>> > Thanks,
>> > Doug
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel  wrote:
>> >>
>> >> 
>> >> Access Denied
>> >>
>> >> You don't have permission to look at Twitter REST API Method:
>> >> friendships
>> >> show.
>> >> 
>> >>
>> >> :)
>> >> -Chad
>> >>
>> >> On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams 
>> >> wrote:
>> >> > We discussed the need to deprecate the  and
>> >> > 
>> >> > elements [1] a few weeks back. We have begun work on the
>> >> > friendships/show
>> >> > method as mentioned in the notice. The method is slightly out of our
>> >> > conventional design, so we are soliciting opinions on its fitness for
>> >> > general use-cases. Please peruse the purposed method's documentation
>> >> > [2]
>> >> > and
>> >> > let us know what you think.
>> >> >
>> >> >
>> >> > 1. http://groups.google.com/group/twitter-development-talk/browse_frm/thread/42ba883b9f8e3c6e
>> >> >
>> >> >
>> >> > 2. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
>> >> > Thanks,
>> >> > Doug
>> >> >
>> >> >
>> >
>> >
>
>

[twitter-dev] Re: Purposed method: friendships/show

Thanks, Chad. I've augmented the usage notes section to explain the
rationale behind the denormalized and redundant data.
Thanks,
Doug




On Tue, Jun 9, 2009 at 9:47 AM, Chad Etzel  wrote:

>
> Taking a look at the json return example:
> {"relationship": {
> "source": {
> "id": 123,
> "screen_name": "bob",
> "following": true,
> "followed_by": false,
> "notifications": false },
>
> "target": {
> "id": 456,
> "screen_name": "jack",
> "following": false,
> "followed_by": true,
> "notifications": null }
> }
> }
>
> In the "source" object (i.e. for "bob"), "following" is true.  Does
> this mean that Bob is following Jack, or vice-versa?
>
> Knowing that, the other 3 following/followed_by value meanings can be
> properly inferred.  Some clarification on the page would help.
>
> -Chad
>
> On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams  wrote:
> > That makes things difficult. Permissions are now public.
> > Thanks,
> > Doug
> >
> >
> >
> >
> >
> > On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel  wrote:
> >>
> >> 
> >> Access Denied
> >>
> >> You don't have permission to look at Twitter REST API Method:
> friendships
> >> show.
> >> 
> >>
> >> :)
> >> -Chad
> >>
> >> On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams 
> wrote:
> >> > We discussed the need to deprecate the  and 
> >> > elements [1] a few weeks back. We have begun work on the
> >> > friendships/show
> >> > method as mentioned in the notice. The method is slightly out of our
> >> > conventional design, so we are soliciting opinions on its fitness for
> >> > general use-cases. Please peruse the purposed method's documentation
> [2]
> >> > and
> >> > let us know what you think.
> >> >
> >> > 1.
> http://groups.google.com/group/twitter-development-talk/browse_frm/thread/42ba883b9f8e3c6e
> >> >
> >> > 2.
> http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
> >> > Thanks,
> >> > Doug
> >> >
> >> >
> >
> >
>

[twitter-dev] Re: Purposed method: friendships/show


Taking a look at the json return example:
{"relationship": {
"source": {
"id": 123,
"screen_name": "bob",
"following": true,
"followed_by": false,
"notifications": false },

"target": {
"id": 456,
"screen_name": "jack",
"following": false,
"followed_by": true,
"notifications": null }
}
}

In the "source" object (i.e. for "bob"), "following" is true.  Does
this mean that Bob is following Jack, or vice-versa?

Knowing that, the other 3 following/followed_by value meanings can be
properly inferred.  Some clarification on the page would help.

-Chad

On Tue, Jun 9, 2009 at 12:40 PM, Doug Williams  wrote:
> That makes things difficult. Permissions are now public.
> Thanks,
> Doug
>
>
>
>
>
> On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel  wrote:
>>
>> 
>> Access Denied
>>
>> You don't have permission to look at Twitter REST API Method: friendships
>> show.
>> 
>>
>> :)
>> -Chad
>>
>> On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams  wrote:
>> > We discussed the need to deprecate the  and 
>> > elements [1] a few weeks back. We have begun work on the
>> > friendships/show
>> > method as mentioned in the notice. The method is slightly out of our
>> > conventional design, so we are soliciting opinions on its fitness for
>> > general use-cases. Please peruse the purposed method's documentation [2]
>> > and
>> > let us know what you think.
>> >
>> > 1. http://groups.google.com/group/twitter-development-talk/browse_frm/thread/42ba883b9f8e3c6e
>> >
>> > 2. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
>> > Thanks,
>> > Doug
>> >
>> >
>
>

[twitter-dev] Re: Purposed method: friendships/show

That makes things difficult. Permissions are now public.
Thanks,
Doug





On Tue, Jun 9, 2009 at 9:39 AM, Chad Etzel  wrote:

>
> 
> Access Denied
>
> You don't have permission to look at Twitter REST API Method: friendships
> show.
> 
>
> :)
> -Chad
>
> On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams  wrote:
> > We discussed the need to deprecate the  and 
> > elements [1] a few weeks back. We have begun work on the friendships/show
> > method as mentioned in the notice. The method is slightly out of our
> > conventional design, so we are soliciting opinions on its fitness for
> > general use-cases. Please peruse the purposed method's documentation [2]
> and
> > let us know what you think.
> > 1.
> http://groups.google.com/group/twitter-development-talk/browse_frm/thread/42ba883b9f8e3c6e
> > 2.
> http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
> > Thanks,
> > Doug
> >
> >
>

[twitter-dev] Re: Purposed method: friendships/show



Access Denied

You don't have permission to look at Twitter REST API Method: friendships show.


:)
-Chad

On Tue, Jun 9, 2009 at 12:32 PM, Doug Williams  wrote:
> We discussed the need to deprecate the  and 
> elements [1] a few weeks back. We have begun work on the friendships/show
> method as mentioned in the notice. The method is slightly out of our
> conventional design, so we are soliciting opinions on its fitness for
> general use-cases. Please peruse the purposed method's documentation [2] and
> let us know what you think.
> 1. http://groups.google.com/group/twitter-development-talk/browse_frm/thread/42ba883b9f8e3c6e
> 2. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show
> Thanks,
> Doug
>
>

[twitter-dev] Purposed method: friendships/show

We discussed the need to deprecate the  and 
elements [1] a few weeks back. We have begun work on the friendships/show
method as mentioned in the notice. The method is slightly out of our
conventional design, so we are soliciting opinions on its fitness for
general use-cases. Please peruse the purposed method's documentation [2] and
let us know what you think.
1.
http://groups.google.com/group/twitter-development-talk/browse_frm/thread/42ba883b9f8e3c6e
2. http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show

Thanks,
Doug

[twitter-dev] Re: friend exist function not working!!!!

2009-06-09 Thread Naveen Kohli

As far twitter API goes, it works fine.I implemented in C#. you can see it
here.

http://www.byteblocks.com/post/2009/05/22/Verify-if-two-twitter-users-are-friends.aspx

May be some JS guru can look thru code and suggest some change.

On Tue, Jun 9, 2009 at 6:16 AM, grand_unifier wrote:

>
> this has been bothering me for quite some tym now...i have written a
> code which inputs two usernames(twitter id) n will o/p if both are
> friends or not...
> the api doc for thsi response is here...
>
> http://apiwiki.twitter.com/Twitter-REST-API-Method:-friendships-exists
>
> 
>
>
>
>
>
>
>$(document).ready(function()
> {
>$('form#search').bind("submit", function(e)
>{
>e.preventDefault();
>$('#content').html('');
>
>var query1 = urlencode($('input[name="user_a"]').val
> ()); //userA
>var query2 = urlencode($('input
> [name="user_b"]').val()); //userB
>
>$.ajax( {
>   url: 'http://twitter.com/
> friendships/exists.json?user_a='+<http://twitter.com/%0Afriendships/exists.json?user_a=%27+>
>query1 +
> '&user_b=' + query2,
>   dataType: "jsonp",
>   success: function(data)
>   {
>if(data ==
> true)
>{
>var
> newDiv = 'true';
>}
>
>$('#content').append(newDiv);
>   }
>
>   });
>
>
>});
>})
>
>  function urlencode(str) {
>return escape(str).replace(/\+/g,'%2B').replace(/%20/g,
> '+').replace(/\*/g, '%2A').replace(/\//g, '%2F').replace(/@/g, '%40');
>  }
>})
>
>
>
> 
>
> the json returns true or falsebut still it doesnt seem to work
> can anyone refine the code???
>
>


-- 
Naveen K Kohli
http://www.netomatix.com

[twitter-dev] Re: How does the "trends" method in search API work?



Hi there,

We don't currently share the secret recipe for making trends and  
there are no plans to as far as I know.


Thanks;
  — Matt Sanford

On Jun 9, 2009, at 5:29 AM, zvn wrote:



Hi,

Sorry, I want to know the algorithm of the API. How does it get top 10
topics in all tweets? Simply by word count ranking? or anything else?

Anyway, thanks for your help! And look forward to get the response
soon.

On Jun 9, 9:29 am, Byteblocks  wrote:

See if these examples help.

http://www.byteblocks.com/post/2009/05/21/Twitter-Daily-Trends-Using-...http://www.byteblocks.com/post/2009/05/22/Get-Weekly-Twitter-Trends.aspx

On Jun 8, 1:18 am, zvn  wrote:




Hi,


I'm a master student in Taiwan. I want to do some work to improve  
the
trends API inhttp://apiwiki.twitter.com/Twitter-Search-API-Method%3A-trends 
.
But I didn't know how does this api work, so it's hard for me to  
make
a comparison between my method and the API, would any doby please  
tell

me how to solve the problem?- Hide quoted text -


- Show quoted text -

[twitter-dev] Re: Getting multiple user profiles in one call



Hi there,

This is not currently possible, you'll need to use the /users/ 
show method for each user, or use the /statuses/friends method to eget  
the full information and page through that way.


Thanks;
 – Matt Sanford / @mzsanford
 Twitter Dev

On Jun 9, 2009, at 12:42 AM, kovshenin wrote:



Hi.

I'm using the http://twitter.com/friends/ids/ REST call to get 5000
twitter ids of friends, now I'd like to know their locations,
preferably in one API call. Is that possible? Couldn't find a function
that would accept multiple twitter ids and return profiles. Did I miss
anything?

Thanks.

[twitter-dev] Re: How does the "trends" method in search API work?

2009-06-09 Thread zvn


Hi,

Sorry, I want to know the algorithm of the API. How does it get top 10
topics in all tweets? Simply by word count ranking? or anything else?

Anyway, thanks for your help! And look forward to get the response
soon.

On Jun 9, 9:29 am, Byteblocks  wrote:
> See if these examples help.
>
> http://www.byteblocks.com/post/2009/05/21/Twitter-Daily-Trends-Using-...http://www.byteblocks.com/post/2009/05/22/Get-Weekly-Twitter-Trends.aspx
>
> On Jun 8, 1:18 am, zvn  wrote:
>
>
>
> > Hi,
>
> > I'm a master student in Taiwan. I want to do some work to improve the
> > trends API inhttp://apiwiki.twitter.com/Twitter-Search-API-Method%3A-trends.
> > But I didn't know how does this api work, so it's hard for me to make
> > a comparison between my method and the API, would any doby please tell
> > me how to solve the problem?- Hide quoted text -
>
> - Show quoted text -

[twitter-dev] friend exist function not working!!!!

2009-06-09 Thread grand_unifier


this has been bothering me for quite some tym now...i have written a
code which inputs two usernames(twitter id) n will o/p if both are
friends or not...
the api doc for thsi response is here...

http://apiwiki.twitter.com/Twitter-REST-API-Method:-friendships-exists








$(document).ready(function()
 {
$('form#search').bind("submit", function(e)
{
e.preventDefault();
$('#content').html('');

var query1 = urlencode($('input[name="user_a"]').val
()); //userA
var query2 = urlencode($('input
[name="user_b"]').val()); //userB

$.ajax( {
   url: 'http://twitter.com/
friendships/exists.json?user_a='+
query1 + 
'&user_b=' + query2,
   dataType: "jsonp",
   success: function(data)
   {
if(data ==
true)
{
var
newDiv = 'true';
}

$('#content').append(newDiv);
   }

   });


});
})

  function urlencode(str) {
return escape(str).replace(/\+/g,'%2B').replace(/%20/g,
'+').replace(/\*/g, '%2A').replace(/\//g, '%2F').replace(/@/g, '%40');
  }
})





the json returns true or falsebut still it doesnt seem to work
can anyone refine the code???

[twitter-dev] Re: How does the "trends" method in search API work?

2009-06-09 Thread Philip Plante

Are you trying to improve the results that Twitter already provides?
If so then you would need a large statistically significant sample in
order to extract this data.

On Jun 8, 12:18 am, zvn  wrote:
> Hi,
>
> I'm a master student in Taiwan. I want to do some work to improve the
> trends API inhttp://apiwiki.twitter.com/Twitter-Search-API-Method%3A-trends.
> But I didn't know how does this api work, so it's hard for me to make
> a comparison between my method and the API, would any doby please tell
> me how to solve the problem?

[twitter-dev] Getting multiple user profiles in one call

2009-06-09 Thread kovshenin


Hi.

I'm using the http://twitter.com/friends/ids/ REST call to get 5000
twitter ids of friends, now I'd like to know their locations,
preferably in one API call. Is that possible? Couldn't find a function
that would accept multiple twitter ids and return profiles. Did I miss
anything?

Thanks.

[twitter-dev] Re: Larger Users Not Returning Follower Data