Re: [twitter-dev] Re: Streaming API TOS

[John Kalucki]

The existing EULA has its confusing parts and is at the end of its life. The
Commercial License is much better conceived and is aligned with where
Twitter is going, and is not based on where we were 12+ months ago when the
EULA first was released.

On Sun, Apr 11, 2010 at 6:16 PM, M. Edward (Ed) Borasky
wrote:

> There is also the issue of what we can do with the Sample and Filter
> endpoints regarding, for example, tweets per day or tweets per second.
> It's not all that difficult or inaccurate to multiply Sample
> ("Spritzer") tweet counts by 20. ;-) I think I'll post this one to the
> question list on Google Moderator.
>
> --
> M. Edward (Ed) Borasky
> http://borasky-research.net/m-edward-ed-borasky/ @znmeb
>
> "A mathematician is a device for turning coffee into theorems." ~ Paul
> Erdős
>
>
> On 04/11/2010 05:54 PM, Dewald Pretorius wrote:
> > Thanks for the quick response, John.
> >
> > The best will then be to wait for post-Chirp.
> >
> > As is, the current EULA could also be interpreted to prevent such
> > uses, and that kind of nebulous wording is no basis upon which to
> > expend any creative or development effort.
> >
> > On Apr 11, 9:20 pm, John Kalucki  wrote:
> >> Both of those use cases are fine. The intent was to prevent people from
> >> publishing counts of Tweets per day or similar metrics. (I make no
> pretense
> >> at defending this intent, I'm the messenger.) Go forth and wordle.
> >>
> >> This EULA is near the end of its life and has been rewritten into the
> >> Commercial Data License, which Doug and Barkari will be discussing on
> day
> >> two of Chirp. If you have questions about how access under the EULA will
> >> evolve to access under the License, that would be a good place to start.
> >>
> >> -John Kaluckihttp://twitter.com/jkalucki
> >> Infrastructure, Twitter Inc.
> >>
> >>
> >>
> >> On Sun, Apr 11, 2010 at 4:22 PM, Dewald Pretorius 
> wrote:
> >>> With reference to:
> >>> http://twitter.com/pdfs/streaming_api_eula.pdf
> >>
> >>> Section 5 (ii) (e):
> >>> "You may only use the Content and Content Feed and any data resulting
> >>> or provided therefrom for internal purposes only and, unless expressly
> >>> authorized herein, you may not publicly release or disclose any data
> >>> or usage statistics or other information (in the aggregate or
> >>> otherwise) regarding the Content."
> >>
> >>> Question:
> >>
> >>> Assumimg I build a website that uses the Streaming API, is my
> >>> interpretation correct that the following is against the TOS?
> >>
> >>> 1) Counting and displaying to the website users how many times the
> >>> word "earthquake" occurs in tweets over a certain period of time.
> >>
> >>> 2) Building and displaying to the website users a tag cloud of words/
> >>> phrases in tweets.- Hide quoted text -
> >>
> >> - Show quoted text -
> >
> >
>
>
> --
> M. Edward (Ed) Borasky
> borasky-research.net/m-edward-ed-borasky
>
> "A mathematician is a device for turning coffee into theorems." ~ Paul
> Erdős
>
>
> --
> To unsubscribe, reply using "remove me" as the subject.
>

Re: [twitter-dev] Re: Upcoming changes to the way status IDs are sequenced

[M. Edward (Ed) Borasky]

On 04/11/2010 09:33 PM, Nick Arnett wrote:
> On Sun, Apr 11, 2010 at 5:14 PM, John Kalucki  wrote:
> 
>>
>> This is useful stuff for dealing with infinite sequences of events -- like,
>> picking a random example, the insertion of new tweets into a materialized
>> timeline (a cache of the timeline vector).
> 
> 
> The Twitter stream is an infinite sequence of events... now that's serious
> optimism about how long Twitter will exist!
> 
> Sorry, just had to say it.
> 
> Of course, some infinities are bigger than others.
> 
> Nick
> 
> 

Ah yes ... and the "tweet rate" is growing "exponentially" ... except
that such growth is economically implausible. Thanks for reminding me -
another Chirp question for Google Moderator. ;-)

--
M. Edward (Ed) Borasky
http://borasky-research.net/m-edward-ed-borasky/ @znmeb

"I've always regarded nature as the clothing of God." ~Alan Hovhaness


-- 
To unsubscribe, reply using "remove me" as the subject.

[twitter-dev] Re: Some thoughts leading up to Chirp

[ConnectMe]

Ryan,

Thanks for taking the time to share your thoughts as well as open up
a direct line to communicate with you. It speaks well of the company
you work for and the opportunity you're trying to manage.

Quite frankly I'm surprised Twitter doesn't acquire more companies.
The last one I really remember was Summize and that was quite
some time ago. I just hope Twitter doesn't fall in the footsteps of
Apple,
whose change to their developer's agreement was one of the worst
I can remember in awhile. But for what it's worth, try to respond to
as many inquiries as possible. I had tweeted some questions a couple
of weeks ago, and when communications suddenly stopped, it was
easy to assume the worst. Perhaps I erred by including a reference to
Yahoo's Project Rushmore. Anyway, mea culpa.

Best of luck!

- Brian



On Apr 11, 6:22 pm, Ryan Sarver  wrote:
> I wanted to email everyone and share my thoughts on the acquisition
> from Friday, the communication around it and where we are going from
> here. We're incredibly excited about Chirp, and I think an open
> dialogue going into it is important. I look forward to meeting many of
> you there and continuing the discussion.
>
> We love the Twitter ecosystem and work hard every day to help support
> you and make the platform you are building on as successful as it can
> be for everyone involved. We love the variety that developers have
> built around the Twitter experience and it's a big part of the success
> we've seen. However when we dug in a little bit we realized that it
> was causing massive confusion among user's who had an iPhone and were
> looking to use Twitter for the first time. They would head to the App
> Store, search for Twitter and would see results that included a lot of
> apps that had nothing to do with Twitter and a few that did, but a new
> user wouldn't find what they were looking for and give up. That is a
> lost user for all of us. This means that we were missing out an
> opportunity to grow the userbase which is beneficial for the health of
> the entire ecosystem. Focus on growing and serving the userbase is
> beneficial to everyone in the ecosystem and more opportunities become
> available with a larger audience. We believe strongly that the
> ecosystem is critical to our success and this move doesn't change
> that. We have analytics that show our most engaged users are ones that
> use SMS, twitter.com AND a 3rd-party application. It further proves
> that there are different audiences and needs that we can never meet on
> our own and we all need to work together to provide what is best for
> the users. Once I understood the long-term view I strongly believed it
> was not only the right thing to do for users, but the right thing to
> do for the ecosystem as a whole.
>
> To be clear, we are going to work hard to improve our product, add new
> functionality, make acquisitions when it's in the best interest of
> users and the whole ecosystem at large. Each one of those things has
> the potential to upset a company or developer that may have been
> building in that space and they then have to look for new ways to
> create value for users. My promise is that we will be consistent in
> always focusing on what's best for the user and the ecosystem as a
> whole and we will be sincere and honest in our communication with you.
> To the point that we can, we will try to give more certainty about the
> areas where we think we can maximize benefit to users. We will
> continue to focus on what is best for users and we will work together
> to make sure that we are creating more opportunities for the ecosystem
> on the whole. We will also admit our mistakes when they are made and
> the Blackberry client should never have been labeled "official". It
> has since been changed and you won't see that language used with
> Twitter clients in the future.
>
> This week will hopefully show that we are focused on building a
> platform that no longer just mirrors twitter.com functionality, but
> offers you raw utility that provides much greater opportunities to
> innovate and build durable, valuable businesses. I also want this week
> to be an opportunity for us to get together and discuss the future of
> the platform and how we can improve our communication, responsiveness
> and clarity. We have an open office hours at 10:15am on Thursday at
> the Hack Day and I invite all of you to come by for a discussion to
> talk about the future of the platform and help us craft a working
> relationship that is beneficial for both of us. I will provide a free
> ticket to anyone from this list that is unable to afford the current
> price so that they can be part of that discussion. Just email me
> directly. For those of you who can't make it to Chirp, it will be live
> streamed so you can tune in from home -- where ever home might be.
>
> As always, you can reach me by email or by phone, 617 763 9904. I am
> here to listen and provide clarity when possible and you should know
> we ar

Re: [twitter-dev] Re: Upcoming changes to the way status IDs are sequenced

[Nick Arnett]

On Sun, Apr 11, 2010 at 5:14 PM, John Kalucki  wrote:

>
> This is useful stuff for dealing with infinite sequences of events -- like,
> picking a random example, the insertion of new tweets into a materialized
> timeline (a cache of the timeline vector).


The Twitter stream is an infinite sequence of events... now that's serious
optimism about how long Twitter will exist!

Sorry, just had to say it.

Of course, some infinities are bigger than others.

Nick


-- 
To unsubscribe, reply using "remove me" as the subject.

RE: [twitter-dev] Some thoughts leading up to Chirp

[Brian Smith]

Ryan Sarver wrote:
> [...] However when we dug
> in a little bit we realized that it was causing massive confusion among
user's who
> had an iPhone and were looking to use Twitter for the first time. They
would
> head to the App Store, search for Twitter and would see results that
included a
> lot of apps that had nothing to do with Twitter and a few that did, but a
new
> user wouldn't find what they were looking for and give up. That is a lost
user for
> all of us.  
>
> [...] We will also admit
> our mistakes when they are made and the Blackberry client should never
have
> been labeled "official". It has since been changed and you won't see that
> language used with Twitter clients in the future.

The "officialness" of the Blackberry app wasn't much of a problem. The
problem was/is the name and the logo. It is confusing to users to have the
app named "Twitter" and it is confusing to see the app branded solely with
the "t" logo. The "t" mark is something that should definitely be protected,
but I think it has a lot of *functional* uses for it as an indicator or
badge that make it inappropriate as the logo for a single application on any
platform. IMO, it would be much better for Twitter in the long run to have
the "t" logo used as a badge to indicate that an app has met some
quality/security criteria--like the "Compatible with Windows 7" logo
program, the "Made for iPod," the Visa logo, etc. That would be something
that would allow you to start a process of ensuring a wide variety of
high-quality applications that are closely aligned with your business goals,
without setting the bar too high or the terms too strict for simpler
applications with a more casual connection to Twitter.

Many mobile operators and phone manufacturers have very bad policies about
supporting their products once they've been replaced with newer models. It
is very likely that, if you let mobile operators and mobile manufacturers
have exclusive uses of the trademarks on their platforms, that those
trademarks will be attached to software that becomes stale, obsolete, or
even totally non-functional on otherwise serviceable devices that aren't
even that old. It would be a big mistake to reserve Twitter's branding for
applications which don't even end up staying in the top tier of Twitter apps
on their platform in terms of quality.

Anyway, I think that everybody will soon see that "officialness" of
competing applications is a very small problem compared to issues like
degradation of UI w/ advertising or strict restrictions on how spam-ish
Twitter-provided content is filtered. I really hope that you guys have
something extremely clever planned for monetization. I have been unable to
think of many ways to make money with Twitter that didn't involve annoying
end-users with ads or encouraging end-users to annoy each other ("RT to
win..."), and AFAICT nothing is going to work unless it keeps users' home
and @mentions timelines clean with less advertising/spam than there already
is now, instead of more. I am genuinely curious to see what you guys have
come up with.

Regards,
Brian
@BRIAN_



-- 
To unsubscribe, reply using "remove me" as the subject.

[twitter-dev] Re: Some thoughts leading up to Chirp

[Justyn]

Regardless of the companies position moving forward, there are great
people working at Twitter who sincerely care about the developer
community, including Ryan. If things are unfair, you can bet they feel
it too. They're still figuring it out. I don't see them implementing
any of the stuff your software does, so I don't understand the
constant negativity. You complained that they weren't communicating,
and when they do you call it BS. Life's too short man.

The whole situation the last few days reminds me a lot of this clip:
http://www.youtube.com/watch?v=KLni3wbndls

Justyn

On Apr 11, 8:05 pm, Dewald Pretorius  wrote:
> Ryan,
>
> Thanks for attempting to step into an emotionally charged environment
> and clarifying things.
>
> However, to be quite frank, the argument about "confusion in the Apple
> app store" gives off a distinct spinning sound. Very loud, in fact. It
> may be one of the reasons for acquiring Tweetie, but to cite it as the
> primary and only reason immediately sets of all flavors of BS alarms.

[twitter-dev] Re: Some thoughts leading up to Chirp

[Mike Champion]

Ryan, thanks for the message. Appreciate the perspective, and looking
forward to continuing the conversation about where the Twitter
platform is going at Chirp. I think the more vision that can be shared
about Twitter's direction, the more that other developers can make
informed decisions.

And learning when Twitter for Mac will get updated ;-)

-mike

On Apr 11, 10:47 pm, Arnaud Meunier 
wrote:
> Thanks for this clarification, Ryan.
>
> I think an important part of the tension is coming from the fact you really
> took your time to (as you say) "dig a little bit", and realize the right
> move was to buy Tweetie. I mean, it’s almost like if it was in Twitter core
> to... have multiple holes, and multiple Apps to fill these holes. Another
> "solution" to the Apple Store confusion problem could have been a list of
> recommended Twitter clients, for example.
>
> With these recent moves and announcements you’re starting to realize (for
> the first time) lots of developer’s fear: "What if Twitter makes that same
> feature I’m working on?"
>
> This situation happened on a lot of other platforms before, and I guess we
> all knew it was going to happen here, soon or later. The only questions were
> When and Who. One of the question is still opened. I hope we’ll find answers
> @chirp :)
>
> Arnaud -http://twitter.com/twitoaster

Re: [twitter-dev] Re: Upcoming changes to the way status IDs are sequenced

[Chad Etzel]

I'd like to see more epsilon-delta proofs on this list personally :)

Chad



On Apr 11, 2010, at 17:14, John Kalucki  wrote:

A sequence can be on a continuum from unsorted to partially sorted  
to roughly sorted to totally sorted. Totally sorted is what we mean  
when we say "sorted". Partially sorted could mean anything, I  
suppose, but roughly sorted is a stricter definition than partially  
sorted. Informally it means that each item is no more than K items  
out of position. So, to totally sort the sequence, you need only  
consider K items.


This is useful stuff for dealing with infinite sequences of events  
-- like, picking a random example, the insertion of new tweets into  
a materialized timeline (a cache of the timeline vector). The events  
get slightly jumbled as they go through the Twitter system and this  
causes confusion for developers who don't understand how we apply  
the CAP theorem. It's Brewer's world, we just live in it. And we  
haven't done a good job at explaining our QoS as we've made the CAP  
trade-offs, or how we've evolved them, etc. etc.


To make things one step more complicated, at Twitter, K is a  
function of a number of factors, including the timeline, the user  
tweeting, the phase of the moon, and the general state of the  
Twitter system. So, we have to think of the distribution of K over  
time as well.


Crazy. We should just move this all into a single instance of Oracle  
and go home.


http://twitter.com/jkalucki/statuses/10503736367
A sequence α is k-sorted IFF ∀ i, r, 1 ≤ i ≤ r ≤ n, i ≤ r  
- k implies aᵢ ≤ aᵣ.


-John Kalucki
http://twitter.com/jkalucki
Infrastructure, Twitter Inc.



On Sun, Apr 11, 2010 at 4:35 PM, Josh Bleecher Snyder > wrote:

Hi John (et al.),

These emails from you are great -- they are exactly the sort of
thoughtful, detailed, specific, technical emails that I would
personally love to see accompany future announcements. I think they
would prevent a fair amount of FUD. Thank you.

I have one stupid question, if you don't mind, though. You refer in
every email to "K". What, precisely, does K refer to? What are its
units? (I think I know what it you mean by it, but I'd be interested
to hear precisely.)

Thanks,
Josh



On Sun, Apr 11, 2010 at 2:23 PM, John Kalucki   
wrote:
> If you are writing a general purpose display app, I think, (but I  
am not at
> all certain), that you can ignore this issue. Reasonable polling  
frequency
> on modest velocity timelines will sometimes, but very rarely, miss  
a tweet.
> Also, over time, we're doing things to make this better for  
everyone. Many
> of our projects have the side-effect of reducing K, decreasing the  
already
> low since_id failure odds even further. Some tweet pipeline  
changes when
> live in the last few weeks that dramatically reduce the K  
distribution for

> various user types.
>
> Since I don't know how the Last-Modified time exactly works, I'm  
going to

> restate your response slightly:
>
> Assuming synchronized clocks (or solely the Twitter Clock, if  
exposed
> properly via Last-Modified), given a poll at time t, the newest  
status is at
> least t - n seconds old, and sufficient n, then even a naive  
since_id
> algorithm will be effectively Exactly Once. Assuming that Twitter  
is running
> normally. For a given poll, when the poll time and last update  
time delta

> drops below this n second period, there's a non-zero loss risk.
>
> Just what is n? It is K expressed as time rather than as a  
discrete count.
> For some timelines types, with some classes of users, K is as much  
as
> perhaps 180 seconds. For others, K is less than 1 second. There's  
some
> variability here that we should characterize more carefully  
internally and
> then discuss publicly. I suspect there's a lot to be learned from  
this

> exercise.
>
> Since_id really runs into trouble when any of the following are  
too great:
> the polling frequency, the updating frequency, the roughly-sorted  
K value.
> If you are polling often to reduce display latency, use the  
Streaming API.

> If the timeline moves too fast to capture it all exactly, you should
> reconsider your requirements or get a Commercial Data License for  
the
> Streaming API. Does the user really need to see every Bieber at 3  
Biebers
> Per Second? How would they ever know if they missed 10^-5 of them  
in a blur?
> If you need them all for analysis, consider calculating the  
confidence
> interval given a sample proportion of 1 - 10^6 (6 9s) or so vs. a  
total
> enumeration. Indistinguishable. If you need them for some other  
purpose, say

> CRM, the Streaming API may be the answer.
>
> -John Kalucki
> http://twitter.com/jkalucki
> Infrastructure, Twitter Inc.
>
>
> On Fri, Apr 9, 2010 at 2:28 PM, Brian Smith   
wrote:

>>
>> John,
>>
>>
>>
>> I am not polling. I am simply trying to implement a basic “refres 
h”
>> feature like every desktop/mobile Twitter app has. Basically, I  
just want to
>> let users scroll through t

Re: [twitter-dev] Re: Some thoughts leading up to Chirp

[Arnaud Meunier]

Thanks for this clarification, Ryan.

I think an important part of the tension is coming from the fact you really
took your time to (as you say) "dig a little bit", and realize the right
move was to buy Tweetie. I mean, it’s almost like if it was in Twitter core
to... have multiple holes, and multiple Apps to fill these holes. Another
"solution" to the Apple Store confusion problem could have been a list of
recommended Twitter clients, for example.

With these recent moves and announcements you’re starting to realize (for
the first time) lots of developer’s fear: "What if Twitter makes that same
feature I’m working on?"

This situation happened on a lot of other platforms before, and I guess we
all knew it was going to happen here, soon or later. The only questions were
When and Who. One of the question is still opened. I hope we’ll find answers
@chirp :)

Arnaud - http://twitter.com/twitoaster


-- 
To unsubscribe, reply using "remove me" as the subject.

[twitter-dev] Re: Some thoughts leading up to Chirp

[Robby Grossman]

Thanks for the post, Ryan. Looking forward to hearing more of both
perspectives later this week.

--Robby

On Apr 11, 8:22 pm, Ryan Sarver  wrote:
> I wanted to email everyone and share my thoughts on the acquisition
> from Friday, the communication around it and where we are going from
> here. We're incredibly excited about Chirp, and I think an open
> dialogue going into it is important. I look forward to meeting many of
> you there and continuing the discussion.
>
> We love the Twitter ecosystem and work hard every day to help support
> you and make the platform you are building on as successful as it can
> be for everyone involved. We love the variety that developers have
> built around the Twitter experience and it's a big part of the success
> we've seen. However when we dug in a little bit we realized that it
> was causing massive confusion among user's who had an iPhone and were
> looking to use Twitter for the first time. They would head to the App
> Store, search for Twitter and would see results that included a lot of
> apps that had nothing to do with Twitter and a few that did, but a new
> user wouldn't find what they were looking for and give up. That is a
> lost user for all of us. This means that we were missing out an
> opportunity to grow the userbase which is beneficial for the health of
> the entire ecosystem. Focus on growing and serving the userbase is
> beneficial to everyone in the ecosystem and more opportunities become
> available with a larger audience. We believe strongly that the
> ecosystem is critical to our success and this move doesn't change
> that. We have analytics that show our most engaged users are ones that
> use SMS, twitter.com AND a 3rd-party application. It further proves
> that there are different audiences and needs that we can never meet on
> our own and we all need to work together to provide what is best for
> the users. Once I understood the long-term view I strongly believed it
> was not only the right thing to do for users, but the right thing to
> do for the ecosystem as a whole.
>
> To be clear, we are going to work hard to improve our product, add new
> functionality, make acquisitions when it's in the best interest of
> users and the whole ecosystem at large. Each one of those things has
> the potential to upset a company or developer that may have been
> building in that space and they then have to look for new ways to
> create value for users. My promise is that we will be consistent in
> always focusing on what's best for the user and the ecosystem as a
> whole and we will be sincere and honest in our communication with you.
> To the point that we can, we will try to give more certainty about the
> areas where we think we can maximize benefit to users. We will
> continue to focus on what is best for users and we will work together
> to make sure that we are creating more opportunities for the ecosystem
> on the whole. We will also admit our mistakes when they are made and
> the Blackberry client should never have been labeled "official". It
> has since been changed and you won't see that language used with
> Twitter clients in the future.
>
> This week will hopefully show that we are focused on building a
> platform that no longer just mirrors twitter.com functionality, but
> offers you raw utility that provides much greater opportunities to
> innovate and build durable, valuable businesses. I also want this week
> to be an opportunity for us to get together and discuss the future of
> the platform and how we can improve our communication, responsiveness
> and clarity. We have an open office hours at 10:15am on Thursday at
> the Hack Day and I invite all of you to come by for a discussion to
> talk about the future of the platform and help us craft a working
> relationship that is beneficial for both of us. I will provide a free
> ticket to anyone from this list that is unable to afford the current
> price so that they can be part of that discussion. Just email me
> directly. For those of you who can't make it to Chirp, it will be live
> streamed so you can tune in from home -- where ever home might be.
>
> As always, you can reach me by email or by phone, 617 763 9904. I am
> here to listen and provide clarity when possible and you should know
> we are committed to working with you on this.
>
> Best, Ryan


-- 
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Re: Streaming API TOS

[M. Edward (Ed) Borasky]

There is also the issue of what we can do with the Sample and Filter
endpoints regarding, for example, tweets per day or tweets per second.
It's not all that difficult or inaccurate to multiply Sample
("Spritzer") tweet counts by 20. ;-) I think I'll post this one to the
question list on Google Moderator.

--
M. Edward (Ed) Borasky
http://borasky-research.net/m-edward-ed-borasky/ @znmeb

"A mathematician is a device for turning coffee into theorems." ~ Paul Erdős


On 04/11/2010 05:54 PM, Dewald Pretorius wrote:
> Thanks for the quick response, John.
> 
> The best will then be to wait for post-Chirp.
> 
> As is, the current EULA could also be interpreted to prevent such
> uses, and that kind of nebulous wording is no basis upon which to
> expend any creative or development effort.
> 
> On Apr 11, 9:20 pm, John Kalucki  wrote:
>> Both of those use cases are fine. The intent was to prevent people from
>> publishing counts of Tweets per day or similar metrics. (I make no pretense
>> at defending this intent, I'm the messenger.) Go forth and wordle.
>>
>> This EULA is near the end of its life and has been rewritten into the
>> Commercial Data License, which Doug and Barkari will be discussing on day
>> two of Chirp. If you have questions about how access under the EULA will
>> evolve to access under the License, that would be a good place to start.
>>
>> -John Kaluckihttp://twitter.com/jkalucki
>> Infrastructure, Twitter Inc.
>>
>>
>>
>> On Sun, Apr 11, 2010 at 4:22 PM, Dewald Pretorius  wrote:
>>> With reference to:
>>> http://twitter.com/pdfs/streaming_api_eula.pdf
>>
>>> Section 5 (ii) (e):
>>> "You may only use the Content and Content Feed and any data resulting
>>> or provided therefrom for internal purposes only and, unless expressly
>>> authorized herein, you may not publicly release or disclose any data
>>> or usage statistics or other information (in the aggregate or
>>> otherwise) regarding the Content."
>>
>>> Question:
>>
>>> Assumimg I build a website that uses the Streaming API, is my
>>> interpretation correct that the following is against the TOS?
>>
>>> 1) Counting and displaying to the website users how many times the
>>> word "earthquake" occurs in tweets over a certain period of time.
>>
>>> 2) Building and displaying to the website users a tag cloud of words/
>>> phrases in tweets.- Hide quoted text -
>>
>> - Show quoted text -
> 
> 


-- 
M. Edward (Ed) Borasky
borasky-research.net/m-edward-ed-borasky

"A mathematician is a device for turning coffee into theorems." ~ Paul Erdős


-- 
To unsubscribe, reply using "remove me" as the subject.

[twitter-dev] Re: Some thoughts leading up to Chirp

[Dewald Pretorius]

Ryan,

Thanks for attempting to step into an emotionally charged environment
and clarifying things.

However, to be quite frank, the argument about "confusion in the Apple
app store" gives off a distinct spinning sound. Very loud, in fact. It
may be one of the reasons for acquiring Tweetie, but to cite it as the
primary and only reason immediately sets of all flavors of BS alarms.


-- 
To unsubscribe, reply using "remove me" as the subject.

[twitter-dev] Re: Streaming API TOS

[Dewald Pretorius]

Thanks for the quick response, John.

The best will then be to wait for post-Chirp.

As is, the current EULA could also be interpreted to prevent such
uses, and that kind of nebulous wording is no basis upon which to
expend any creative or development effort.

On Apr 11, 9:20 pm, John Kalucki  wrote:
> Both of those use cases are fine. The intent was to prevent people from
> publishing counts of Tweets per day or similar metrics. (I make no pretense
> at defending this intent, I'm the messenger.) Go forth and wordle.
>
> This EULA is near the end of its life and has been rewritten into the
> Commercial Data License, which Doug and Barkari will be discussing on day
> two of Chirp. If you have questions about how access under the EULA will
> evolve to access under the License, that would be a good place to start.
>
> -John Kaluckihttp://twitter.com/jkalucki
> Infrastructure, Twitter Inc.
>
>
>
> On Sun, Apr 11, 2010 at 4:22 PM, Dewald Pretorius  wrote:
> > With reference to:
> >http://twitter.com/pdfs/streaming_api_eula.pdf
>
> > Section 5 (ii) (e):
> > "You may only use the Content and Content Feed and any data resulting
> > or provided therefrom for internal purposes only and, unless expressly
> > authorized herein, you may not publicly release or disclose any data
> > or usage statistics or other information (in the aggregate or
> > otherwise) regarding the Content."
>
> > Question:
>
> > Assumimg I build a website that uses the Streaming API, is my
> > interpretation correct that the following is against the TOS?
>
> > 1) Counting and displaying to the website users how many times the
> > word "earthquake" occurs in tweets over a certain period of time.
>
> > 2) Building and displaying to the website users a tag cloud of words/
> > phrases in tweets.- Hide quoted text -
>
> - Show quoted text -


-- 
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Storing information from the API

[Abraham Williams]

Historically Twitter had imposed no limits on length of storage with the
understanding that you treat the users wishes with respect. Private,
deleted, and geo information should especially be handled with care. Be
aware though that for your own protection it is best to have a qualified
individual verify this with Twitter's published TOS and API rules and be
aware that those could change at anytime.

Abraham

2010/4/9 Dean Collins 

>  Come on Andy, he’s asking the Twitter Dev list , a highly appropriate
> place to ask if he couldn’t find the answer elsewhere.
>
>
>
> Hardly random strangers, this question must have come up before.
>
>
>
> Regards,
>
> Dean Collins
> Live Chat Concepts Inc
> d...@livechatconcepts.com
>  +1-212-203-4357   New York
> +61-2-9016-5642   (Sydney in-dial).
> +44-20-3129-6001 (London in-dial).
>   --
>
> On Fri, Apr 9, 2010 at 01:43, Andrew Badera  wrote:
>
> Have you read the EULA(s) ?
>
> In legal matters it's usually best to do your own footwork on the fine
> print first and foremost, rather than trusting a list of Internet
> strangers.
>
> ∞ Andy Badera
> ∞ +1 518-641-1280 Google Voice
> ∞ This email is: [ ] bloggable [x] ask first [ ] private
> ∞ Google me: http://www.google.com/search?q=andrew%20badera
>
>
>
>
> On Thu, Apr 8, 2010 at 8:56 PM, P L  wrote:
> > Hi,
> >  I'm trying to a pull in a user's profile picture and use it as their
> > profile picture on my site. Am I allowed to store the URL in my
> > database (until the user deletes the account/removes the image)? Or
> > are there terms in the Twitter API which suggests that I'm not allowed
> > to store information obtained from the API?
> > Thanks
> >
>
>   --
> To unsubscribe, reply using "remove me" as the subject.
>
>
>
>
> --
> Abraham Williams | Community Advocate | http://abrah.am
> PoseurTech Labs | Projects | http://labs.poseurtech.com
> This email is: [ ] shareable [x] ask first [ ] private.
>



-- 
Abraham Williams | Developer for hire | http://abrah.am
PoseurTech Labs | Projects | http://labs.poseurtech.com
This email is: [ ] shareable [x] ask first [ ] private.

[twitter-dev] Some thoughts leading up to Chirp

[Ryan Sarver]

I wanted to email everyone and share my thoughts on the acquisition
from Friday, the communication around it and where we are going from
here. We're incredibly excited about Chirp, and I think an open
dialogue going into it is important. I look forward to meeting many of
you there and continuing the discussion.

We love the Twitter ecosystem and work hard every day to help support
you and make the platform you are building on as successful as it can
be for everyone involved. We love the variety that developers have
built around the Twitter experience and it's a big part of the success
we've seen. However when we dug in a little bit we realized that it
was causing massive confusion among user's who had an iPhone and were
looking to use Twitter for the first time. They would head to the App
Store, search for Twitter and would see results that included a lot of
apps that had nothing to do with Twitter and a few that did, but a new
user wouldn't find what they were looking for and give up. That is a
lost user for all of us. This means that we were missing out an
opportunity to grow the userbase which is beneficial for the health of
the entire ecosystem. Focus on growing and serving the userbase is
beneficial to everyone in the ecosystem and more opportunities become
available with a larger audience. We believe strongly that the
ecosystem is critical to our success and this move doesn't change
that. We have analytics that show our most engaged users are ones that
use SMS, twitter.com AND a 3rd-party application. It further proves
that there are different audiences and needs that we can never meet on
our own and we all need to work together to provide what is best for
the users. Once I understood the long-term view I strongly believed it
was not only the right thing to do for users, but the right thing to
do for the ecosystem as a whole.

To be clear, we are going to work hard to improve our product, add new
functionality, make acquisitions when it's in the best interest of
users and the whole ecosystem at large. Each one of those things has
the potential to upset a company or developer that may have been
building in that space and they then have to look for new ways to
create value for users. My promise is that we will be consistent in
always focusing on what's best for the user and the ecosystem as a
whole and we will be sincere and honest in our communication with you.
To the point that we can, we will try to give more certainty about the
areas where we think we can maximize benefit to users. We will
continue to focus on what is best for users and we will work together
to make sure that we are creating more opportunities for the ecosystem
on the whole. We will also admit our mistakes when they are made and
the Blackberry client should never have been labeled "official". It
has since been changed and you won't see that language used with
Twitter clients in the future.

This week will hopefully show that we are focused on building a
platform that no longer just mirrors twitter.com functionality, but
offers you raw utility that provides much greater opportunities to
innovate and build durable, valuable businesses. I also want this week
to be an opportunity for us to get together and discuss the future of
the platform and how we can improve our communication, responsiveness
and clarity. We have an open office hours at 10:15am on Thursday at
the Hack Day and I invite all of you to come by for a discussion to
talk about the future of the platform and help us craft a working
relationship that is beneficial for both of us. I will provide a free
ticket to anyone from this list that is unable to afford the current
price so that they can be part of that discussion. Just email me
directly. For those of you who can't make it to Chirp, it will be live
streamed so you can tune in from home -- where ever home might be.

As always, you can reach me by email or by phone, 617 763 9904. I am
here to listen and provide clarity when possible and you should know
we are committed to working with you on this.

Best, Ryan


-- 
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Streaming API TOS

[John Kalucki]

Both of those use cases are fine. The intent was to prevent people from
publishing counts of Tweets per day or similar metrics. (I make no pretense
at defending this intent, I'm the messenger.) Go forth and wordle.

This EULA is near the end of its life and has been rewritten into the
Commercial Data License, which Doug and Barkari will be discussing on day
two of Chirp. If you have questions about how access under the EULA will
evolve to access under the License, that would be a good place to start.

-John Kalucki
http://twitter.com/jkalucki
Infrastructure, Twitter Inc.


On Sun, Apr 11, 2010 at 4:22 PM, Dewald Pretorius  wrote:

> With reference to:
> http://twitter.com/pdfs/streaming_api_eula.pdf
>
> Section 5 (ii) (e):
> "You may only use the Content and Content Feed and any data resulting
> or provided therefrom for internal purposes only and, unless expressly
> authorized herein, you may not publicly release or disclose any data
> or usage statistics or other information (in the aggregate or
> otherwise) regarding the Content."
>
> Question:
>
> Assumimg I build a website that uses the Streaming API, is my
> interpretation correct that the following is against the TOS?
>
> 1) Counting and displaying to the website users how many times the
> word "earthquake" occurs in tweets over a certain period of time.
>
> 2) Building and displaying to the website users a tag cloud of words/
> phrases in tweets.
>


-- 
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Re: Upcoming changes to the way status IDs are sequenced

[John Kalucki]

A sequence can be on a continuum from unsorted to partially sorted to
roughly sorted to totally sorted. Totally sorted is what we mean when we say
"sorted". Partially sorted could mean anything, I suppose, but roughly
sorted is a stricter definition than partially sorted. Informally it means
that each item is no more than K items out of position. So, to totally sort
the sequence, you need only consider K items.

This is useful stuff for dealing with infinite sequences of events -- like,
picking a random example, the insertion of new tweets into a materialized
timeline (a cache of the timeline vector). The events get slightly jumbled
as they go through the Twitter system and this causes confusion for
developers who don't understand how we apply the CAP theorem. It's Brewer's
world, we just live in it. And we haven't done a good job at explaining our
QoS as we've made the CAP trade-offs, or how we've evolved them, etc. etc.

To make things one step more complicated, at Twitter, K is a function of a
number of factors, including the timeline, the user tweeting, the phase of
the moon, and the general state of the Twitter system. So, we have to think
of the distribution of K over time as well.

Crazy. We should just move this all into a single instance of Oracle and go
home.

http://twitter.com/jkalucki/statuses/10503736367
A sequence α is k-sorted IFF ∀ i, r, 1 ≤ i ≤ r ≤ n, i ≤ r - k implies aᵢ ≤
aᵣ.

-John Kalucki
http://twitter.com/jkalucki
Infrastructure, Twitter Inc.



On Sun, Apr 11, 2010 at 4:35 PM, Josh Bleecher Snyder
wrote:

> Hi John (et al.),
>
> These emails from you are great -- they are exactly the sort of
> thoughtful, detailed, specific, technical emails that I would
> personally love to see accompany future announcements. I think they
> would prevent a fair amount of FUD. Thank you.
>
> I have one stupid question, if you don't mind, though. You refer in
> every email to "K". What, precisely, does K refer to? What are its
> units? (I think I know what it you mean by it, but I'd be interested
> to hear precisely.)
>
> Thanks,
> Josh
>
>
>
> On Sun, Apr 11, 2010 at 2:23 PM, John Kalucki  wrote:
> > If you are writing a general purpose display app, I think, (but I am not
> at
> > all certain), that you can ignore this issue. Reasonable polling
> frequency
> > on modest velocity timelines will sometimes, but very rarely, miss a
> tweet.
> > Also, over time, we're doing things to make this better for everyone.
> Many
> > of our projects have the side-effect of reducing K, decreasing the
> already
> > low since_id failure odds even further. Some tweet pipeline changes when
> > live in the last few weeks that dramatically reduce the K distribution
> for
> > various user types.
> >
> > Since I don't know how the Last-Modified time exactly works, I'm going to
> > restate your response slightly:
> >
> > Assuming synchronized clocks (or solely the Twitter Clock, if exposed
> > properly via Last-Modified), given a poll at time t, the newest status is
> at
> > least t - n seconds old, and sufficient n, then even a naive since_id
> > algorithm will be effectively Exactly Once. Assuming that Twitter is
> running
> > normally. For a given poll, when the poll time and last update time delta
> > drops below this n second period, there's a non-zero loss risk.
> >
> > Just what is n? It is K expressed as time rather than as a discrete
> count.
> > For some timelines types, with some classes of users, K is as much as
> > perhaps 180 seconds. For others, K is less than 1 second. There's some
> > variability here that we should characterize more carefully internally
> and
> > then discuss publicly. I suspect there's a lot to be learned from this
> > exercise.
> >
> > Since_id really runs into trouble when any of the following are too
> great:
> > the polling frequency, the updating frequency, the roughly-sorted K
> value.
> > If you are polling often to reduce display latency, use the Streaming
> API.
> > If the timeline moves too fast to capture it all exactly, you should
> > reconsider your requirements or get a Commercial Data License for the
> > Streaming API. Does the user really need to see every Bieber at 3 Biebers
> > Per Second? How would they ever know if they missed 10^-5 of them in a
> blur?
> > If you need them all for analysis, consider calculating the confidence
> > interval given a sample proportion of 1 - 10^6 (6 9s) or so vs. a total
> > enumeration. Indistinguishable. If you need them for some other purpose,
> say
> > CRM, the Streaming API may be the answer.
> >
> > -John Kalucki
> > http://twitter.com/jkalucki
> > Infrastructure, Twitter Inc.
> >
> >
> > On Fri, Apr 9, 2010 at 2:28 PM, Brian Smith 
> wrote:
> >>
> >> John,
> >>
> >>
> >>
> >> I am not polling. I am simply trying to implement a basic “refresh”
> >> feature like every desktop/mobile Twitter app has. Basically, I just
> want to
> >> let users scroll through their timelines, and be reasonably sure that I
> am
> >> presenting them wit

Re: [twitter-dev] Re: Upcoming changes to the way status IDs are sequenced

[Josh Bleecher Snyder]

Hi John (et al.),

These emails from you are great -- they are exactly the sort of
thoughtful, detailed, specific, technical emails that I would
personally love to see accompany future announcements. I think they
would prevent a fair amount of FUD. Thank you.

I have one stupid question, if you don't mind, though. You refer in
every email to "K". What, precisely, does K refer to? What are its
units? (I think I know what it you mean by it, but I'd be interested
to hear precisely.)

Thanks,
Josh



On Sun, Apr 11, 2010 at 2:23 PM, John Kalucki  wrote:
> If you are writing a general purpose display app, I think, (but I am not at
> all certain), that you can ignore this issue. Reasonable polling frequency
> on modest velocity timelines will sometimes, but very rarely, miss a tweet.
> Also, over time, we're doing things to make this better for everyone. Many
> of our projects have the side-effect of reducing K, decreasing the already
> low since_id failure odds even further. Some tweet pipeline changes when
> live in the last few weeks that dramatically reduce the K distribution for
> various user types.
>
> Since I don't know how the Last-Modified time exactly works, I'm going to
> restate your response slightly:
>
> Assuming synchronized clocks (or solely the Twitter Clock, if exposed
> properly via Last-Modified), given a poll at time t, the newest status is at
> least t - n seconds old, and sufficient n, then even a naive since_id
> algorithm will be effectively Exactly Once. Assuming that Twitter is running
> normally. For a given poll, when the poll time and last update time delta
> drops below this n second period, there's a non-zero loss risk.
>
> Just what is n? It is K expressed as time rather than as a discrete count.
> For some timelines types, with some classes of users, K is as much as
> perhaps 180 seconds. For others, K is less than 1 second. There's some
> variability here that we should characterize more carefully internally and
> then discuss publicly. I suspect there's a lot to be learned from this
> exercise.
>
> Since_id really runs into trouble when any of the following are too great:
> the polling frequency, the updating frequency, the roughly-sorted K value.
> If you are polling often to reduce display latency, use the Streaming API.
> If the timeline moves too fast to capture it all exactly, you should
> reconsider your requirements or get a Commercial Data License for the
> Streaming API. Does the user really need to see every Bieber at 3 Biebers
> Per Second? How would they ever know if they missed 10^-5 of them in a blur?
> If you need them all for analysis, consider calculating the confidence
> interval given a sample proportion of 1 - 10^6 (6 9s) or so vs. a total
> enumeration. Indistinguishable. If you need them for some other purpose, say
> CRM, the Streaming API may be the answer.
>
> -John Kalucki
> http://twitter.com/jkalucki
> Infrastructure, Twitter Inc.
>
>
> On Fri, Apr 9, 2010 at 2:28 PM, Brian Smith  wrote:
>>
>> John,
>>
>>
>>
>> I am not polling. I am simply trying to implement a basic “refresh”
>> feature like every desktop/mobile Twitter app has. Basically, I just want to
>> let users scroll through their timelines, and be reasonably sure that I am
>> presenting them with an accurate & complete view of the timeline, while
>> using as little bandwidth as possible.
>>
>>
>>
>> When I said “10 seconds old”/“30 seconds old”/etc. I was referring to I
>> was referring to the age at the time the page of tweets was generated. So,
>> basically, if the tweet’s timestamp – the response’s Last-Modified time more
>> than 10,000 ms (from what you said below), you are almost definitely getting
>> At Least Once behavior if Twitter is operating normally, and you can use
>> that information to get At Least Once behavior that emulates Exactly Once
>> behavior with little (usually no) overhead. Is that a correct interpretation
>> of what you were saying?
>>
>>
>>
>> Thanks,
>>
>> Brian
>>
>>
>>
>>
>>
>> From: twitter-development-talk@googlegroups.com
>> [mailto:twitter-development-t...@googlegroups.com] On Behalf Of John Kalucki
>> Sent: Friday, April 09, 2010 3:31 PM
>> To: twitter-development-talk@googlegroups.com
>> Subject: Re: [twitter-dev] Re: Upcoming changes to the way status IDs are
>> sequenced
>>
>>
>>
>> Your second paragraph doesn't quite make sense. The period between your
>> next poll and the timestamp of the last status is irrelevant. The issue is
>> solely the magnitude of K on the roughly sorted stream of events that are
>> applied to the materialized timeline vector. As K varies, so do the odds,
>> however infinitesimally small, that you will miss a tweet using the last
>> status id returned. The period between your polls of the API does not affect
>> this K.
>>
>> My recommendation is to ignore this issue in nearly every use case. If you
>> are, however, polling high velocity timelines (including search queries) and
>> attempting to approximate an Exactly Once QoS,

[twitter-dev] Streaming API TOS

[Dewald Pretorius]

With reference to:
http://twitter.com/pdfs/streaming_api_eula.pdf

Section 5 (ii) (e):
"You may only use the Content and Content Feed and any data resulting
or provided therefrom for internal purposes only and, unless expressly
authorized herein, you may not publicly release or disclose any data
or usage statistics or other information (in the aggregate or
otherwise) regarding the Content."

Question:

Assumimg I build a website that uses the Streaming API, is my
interpretation correct that the following is against the TOS?

1) Counting and displaying to the website users how many times the
word "earthquake" occurs in tweets over a certain period of time.

2) Building and displaying to the website users a tag cloud of words/
phrases in tweets.

Re: [twitter-dev] Re: Twitter API - users/search - Help Required

[Raffi Krikorian]

ok - sorry - i was thrown off by "ipad".  the results should change, but the
velocity of change may depend.  name search results are ordered so the
"best" results are further up -- new users who get added to the system may
not make the top 1000 users that namesearch can return.  as users are active
in the system, use twitter, engage people, etc., their ranking in name
search will move up.

does that answer the question?

On Sun, Apr 11, 2010 at 11:39 AM, Jimmy  wrote:

> Raffi and Nic, thanks for replying :)
>
> Yes, I'm concerned with the user search and by mistake I wrote "ipad",
> I should have written some name!
>
> Now  please let me know whether the result should be changed or I'll
> keep getting the stale result. I reckon twitter keep
>
> getting new users every next minute then why API returns the same old
> result and that is also to some extend.
>
> Does API result change ?
>
>
>
> On Apr 11, 5:28 pm, Nic Ross  wrote:
> > Ok don't take it here an example for "ipad" may be it was his
> > mistake.
> >
> > Lets say take an example for any common names like "James" or "Chang"
> > or "Chen" don't you expect there will be far more results than 1000
> > So, the point he is making here is will twitter keep the same result
> > of 1000 users for every an authenticated user for any particular time
> > duration or unlimitedly ?
> >
> > I think Jimmy can put some more light on the issue :)
> >
> > On Apr 11, 10:15 pm, Raffi Krikorian  wrote:
> >
> >
> >
> > > Well, with name search the users are not going to change much.  How
> > > many users do you expect to have the name "ipad" (even with the rate
> > > that users are being created).
> >
> > > Am I confused?
> >
> > > On Apr 11, 2010, at 1:01 PM, Nic Ross  wrote:
> >
> > > > Sorry I didn't see my last reply so I am posting it again
> >
> > > > @Raffi Krikorian
> >
> > > > I think Jimmy is asking for searching users not tweets. Look at his
> > > > URLs they contain "users/search" and also "users/search" API call
> > > > limits the result to 1000 (20
> > > > result each page) which he is mentioning.
> >
> > > > The search API which you are suggestion is used to search Tweets not
> > > > users.
> >
> > > > Regards
> > > > Nic
> >
> > > > On Apr 11, 9:39 pm, Raffi Krikorian  wrote:
> > > >> do you mean to be using "name search", or the general search API?
> > > >> Try
> > > >> using the search endpoint at search.twitter.con.
> >
> > > >> On Apr 11, 2010, at 11:48 AM, Jimmy  wrote:
> >
> > > >>> Hi,
> >
> > > >>> I'm working on search api and and came across a problem. Here is my
> > > >>> query:
> >
> > > >>>http://api.twitter.com/1/users/search.json?q=ipad&page=1
> >
> > > >>> The result which I got is constant and never changes. I checked the
> > > >>> result after some span of time like: after 1-2 hours  but I got the
> > > >>> same result.
> >
> > > >>> As per API we can only retrieve first 1000 matches in 50 pages(20
> > > >>> result each page) so does it mean that for life long I will keep
> > > >>> getting the same result for the same query? I mean that is weird!
> >
> > > >>> I also matched the result of second and third page
> >
> > > >>>http://api.twitter.com/1/users/search.json?q=ipad&page=2
> > > >>>http://api.twitter.com/1/users/search.json?q=ipad&page=3
> >
> > > >>> within the span of 1-2 hours but the result was same each time.
> >
> > > >>> Any kind of help will be appreciatable.
> >
> > > >>> --
> > > >>> To unsubscribe, reply using "remove me" as the subject.
>



-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

Re: [twitter-dev] Re: Is it safe to authenticate and send requests via OAuth using Javascript

[Raffi Krikorian]

yup!  that's the one.  sorry - i've been offline for a few hours.

i really rather the twitter-dev mailing list -not- turn into a conversation
about this draft (at least, not until its in a more solid state), but if you
have questions/suggestions/etc., please feel free to mail me directly.

On Sun, Apr 11, 2010 at 1:38 PM, Abraham Williams <4bra...@gmail.com> wrote:

>
> http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth.txt
>
>
> On Sun, Apr 11, 2010 at 13:35, Zhami  wrote:
>
>> +10 Please do circulate the draft!! This is very much of interest to
>> me.
>>
>> On Apr 11, 11:42 am, Raffi Krikorian  wrote:
>> > just to follow up on this, we're working on an oauth 2.0
>> > implementation (of which we are contributors/authors to the spec).
>> > that does have a profile which makes it possible to write JavaScript
>> > oauth clients without compromising the keys.  I can't give a date yet,
>> > however, as the spec is not even finalized yet.  if people are
>> > interested, I can circulate a URL to the draft.
>>
>>
>>
>> --
>> To unsubscribe, reply using "remove me" as the subject.
>>
>
>
>
> --
> Abraham Williams | Developer for hire | http://abrah.am
> PoseurTech Labs | Projects | http://labs.poseurtech.com
> This email is: [ ] shareable [x] ask first [ ] private.
>



-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

[twitter-dev] Re: users/show raises 404 when using user_id; works fine for screen_name

[ryan baldwin]

Yea, I just noticed that warning in the docs... might be beneficial to
put it "above the fold" as that's fairly critical stuff.

Thanks.

On Apr 11, 1:55 pm, Abraham Williams <4bra...@gmail.com> wrote:
> Fromhttp://apiwiki.twitter.com/Twitter-Search-API-Method:-search
>
> Warning: The user ids in the Search API are different from those in the
>
> > REST API (about the two APIs ). 
> > This
> > defect is being tracked by Issue 
> > 214.
> > This means that the to_user_id and from_user_id field vary from the
> > actualy user id on Twitter.com. Applications will have to perform a screen
> > name-based lookup with the 
> > users/show
> >  method
> > to get the correct user id if necessary.
>
> You will see 
> fromhttp://api.twitter.com/users/show.json?screen_name=katie_wallsthat the
> actual user id is 75030777.
>
> Abraham
>
>
>
>
>
> On Sun, Apr 11, 2010 at 12:07, ryan baldwin  wrote:
> > Hey all, I've noticed some very odd and inconsistent behaviour over
> > the past couple days that has me stumped.  When I use the users/show
> > endpoint using user_id the response produces a 404. When I use
> > screen_name of that same user everything works fine. Anybody know what
> > the scoop is?
>
> > here are a couple of examples:
> > {
> >      u'iso_language_code':u'en',
> >      u'text':u'Twittering from the eye doctors office. Its kinda
> > really boring here',
> >      u'created_at':u'Sat,
> >      10      Apr 2010 16:20:50      +',
> >      u'profile_image_url':      u'http://a3.twimg.com/profile_images/
> > 770801237/CIMG5940_normal.JPG',
> >      u'source':      u' > rel="nofollow">UberTwitter',
> >      u'location':      u'ÜT:52.138437,
> >      -106.667903      ', u'      from_user':u'katie_walls',
> >      u'from_user_id':53548499,
> >      u'to_user_id':None,
> >      u'geo':None,
> >      u'id':11944382350      L,
> >      u'metadata':{
> >         u'result_type':u'recent'
> >      }
>
> >http://api.twitter.com/users/show.json?user_id=53548499(404)
> >http://api.twitter.com/users/show.json?screen_name=katie_walls(200,
> > works fine)
>
> > Any ideas? I'm at a complete loss and I'm really not looking forward
> > to the repair costs of the hole I've made in the wall with the top of
> > my head.
>
> > Thanks!
>
> > - ryan.
>
> > --
> > To unsubscribe, reply using "remove me" as the subject.
>
> --
> Abraham Williams | Developer for hire |http://abrah.am
> PoseurTech Labs | Projects |http://labs.poseurtech.com
> This email is: [ ] shareable [x] ask first [ ] private.

Re: [twitter-dev] Re: Is it safe to authenticate and send requests via OAuth using Javascript

[Abraham Williams]

http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth.txt

On Sun, Apr 11, 2010 at 13:35, Zhami  wrote:

> +10 Please do circulate the draft!! This is very much of interest to
> me.
>
> On Apr 11, 11:42 am, Raffi Krikorian  wrote:
> > just to follow up on this, we're working on an oauth 2.0
> > implementation (of which we are contributors/authors to the spec).
> > that does have a profile which makes it possible to write JavaScript
> > oauth clients without compromising the keys.  I can't give a date yet,
> > however, as the spec is not even finalized yet.  if people are
> > interested, I can circulate a URL to the draft.
>
>
>
> --
> To unsubscribe, reply using "remove me" as the subject.
>



-- 
Abraham Williams | Developer for hire | http://abrah.am
PoseurTech Labs | Projects | http://labs.poseurtech.com
This email is: [ ] shareable [x] ask first [ ] private.

[twitter-dev] Re: Is it safe to authenticate and send requests via OAuth using Javascript

[Zhami]

+10 Please do circulate the draft!! This is very much of interest to
me.

On Apr 11, 11:42 am, Raffi Krikorian  wrote:
> just to follow up on this, we're working on an oauth 2.0  
> implementation (of which we are contributors/authors to the spec).  
> that does have a profile which makes it possible to write JavaScript  
> oauth clients without compromising the keys.  I can't give a date yet,  
> however, as the spec is not even finalized yet.  if people are  
> interested, I can circulate a URL to the draft.



-- 
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Re: Twitter REST API Method: POST /:user/:list_id/members ???

[Raffi Krikorian]

Probably not that one right now - we're prioritizing getting  
everything up else to 20 or 100 of stuff per call first.




On Apr 11, 2010, at 4:01 PM, adamjamesdrew  wrote:


Thanks for the reply Raffi.
Are their any plans to bulk-ify the 200 tweets per page limit? It
would reduce the # of calls when the 3200 max tweets are needed.

Thanks
Adam

On Apr 11, 6:09 am, Tim Haines  wrote:
Raffi - I'd love it if I could look up 500 list member's ids at a  
time.
 Don't need the full user object, just the ids.  User objects would  
be a

bonus.

Tim.



On Sun, Apr 11, 2010 at 3:09 PM, Raffi Krikorian  
 wrote:
not yet, right now.  but that's a good idea -- we've been on a  
kick of

"bulk-ifying" our methods, and i'll add that to our list.


On Sat, Apr 10, 2010 at 2:24 PM, adamjamesdrew  
wrote:



Twitter REST API Method: POST /:user/:list_id/members



http://api.twitter.com/1/user/list_id/members.format



Can you add more than one user at a time?



--
To unsubscribe, reply using "remove me" as the subject.



--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

[twitter-dev] Re: Twitter buying Tweetie

[Zhami]

On Apr 10, 7:04 pm, zn...@comcast.net wrote:
> I think we've pretty much exhausted the holes and dirt metaphor, and I'd like 
> to propose a different one. A business is defined by the answer(s) to the 
> question, "Who is going to sell what to whom?" So, what are the needs of the 
> Twitter "customer base?"

Looking for needs in the Twitter "customer base" may not (in fact,
likely doesn't) lead to product ideation that is safe from Twitter
"predation" -- yes, I use a heavily loaded term (predation), but do
not mean it in any negative way at all. If one looks for needs in the
Twitter customer base, solutions should clearly be understood as being
in the realm of what Twitter will asses and potentially directly
provide. After all, definitionally these have been called Twitter's
customer base.

The (relative) newness of Twitter-type functionality coupled with the
(relative) openness of the API has brought many devs into the
community. It is perhaps fun or perhaps intellectually interesting to
build Twitter-centric "inward facing" apps, but I pose the question of
whether these are providing the kind of services that are
intrinsically able to support a business?  If not, these are apps that
one can't expect to monetize, except perhaps indirectly (e.g. ads
based on traffic to a Web site). --> If Twitter is having a long road
to revenue why should it be any different for a Twitter "hole
filler" ?

An alternative is to look for needs in a customer segment that isn't
directly a Twitter segment, but one in which the use of Twitter
enables functionality that serves that segment with a product/service
that is better than what that customer segment presently has available
(if there even is any equivalent offering). This, I believe, is what
Jesse Stay was imploring in his post.

This is not to say that there isn't room for Twitter client apps that
provide access to the Twitter tweet stream -- if-and-only-if done in
some compellingly unique way(s). But the mere existence of any such
"tool" does not imply that it is a monetizable tool. Adoption,
monetization, and resistance to predation require that a tool have a
layer of value-add that is not directly (nor easily) emulated.

I propose that far too many devs in the Twitter community have labored
to build Twitter-centric services but haven't abided by the precepts
the "fast startup" movement. In particular, put out a MVP (Minimally
Viable Product) early, and get customer feedback especially against
the question: will anyone pay? --- at least if one is not expecting to
provide their tool or service long-term without revenue. To do that
requires very deep resources, of the likes that Twitter has, and few
if any of us independent devs can sustain in that context.

In my mind, don't think of Twitter now having Tweetie as locking up,
say, the iPhone market (and by extension - please don't be surprised -
the iPad market), but rather this is a wake-up call to envision a
product for the iPhone/iPad/Android/xxx that gives some customer
segment an ability it presently does not have, a service which may use
Twitter but isn't *about* Twitter. Such will be market-spaces that
Twitter likely won't pursue, and even if they did, market dominance
can be retained by an independent dev because the product isn't about
Twitter, but about the needs of that market segment. For example: help
some group, say doctors in a practice, or delivery people, or in-field
service technicians, better coordinate using real-time messaging --
don't consider this "Twitter" even though Twitter may be an (or even
be "the") underlying enabling technology. This, I suggest, is what
Fred Wilson was writing about.

In summary, my exhortation here, in advance of Chirp, is: it's about
time for the community to become "outward facing" rather than "inward
facing."

My $0.02. Hope it's helpful. No offense meant to anyone.

[twitter-dev] Re: Twitter REST API Method: POST /:user/:list_id/members ???

[adamjamesdrew]

Thanks for the reply Raffi.
Are their any plans to bulk-ify the 200 tweets per page limit? It
would reduce the # of calls when the 3200 max tweets are needed.

Thanks
Adam

On Apr 11, 6:09 am, Tim Haines  wrote:
> Raffi - I'd love it if I could look up 500 list member's ids at a time.
>  Don't need the full user object, just the ids.  User objects would be a
> bonus.
>
> Tim.
>
>
>
> On Sun, Apr 11, 2010 at 3:09 PM, Raffi Krikorian  wrote:
> > not yet, right now.  but that's a good idea -- we've been on a kick of
> > "bulk-ifying" our methods, and i'll add that to our list.
>
> > On Sat, Apr 10, 2010 at 2:24 PM, adamjamesdrew wrote:
>
> >> Twitter REST API Method: POST /:user/:list_id/members
>
> >>http://api.twitter.com/1/user/list_id/members.format
>
> >> Can you add more than one user at a time?
>
> >> --
> >> To unsubscribe, reply using "remove me" as the subject.
>
> > --
> > Raffi Krikorian
> > Twitter Platform Team
> >http://twitter.com/raffi

Re: [twitter-dev] users/show raises 404 when using user_id; works fine for screen_name

[Abraham Williams]

>From http://apiwiki.twitter.com/Twitter-Search-API-Method:-search

Warning: The user ids in the Search API are different from those in the
> REST API (about the two APIs ). This
> defect is being tracked by Issue 
> 214.
> This means that the to_user_id and from_user_id field vary from the
> actualy user id on Twitter.com. Applications will have to perform a screen
> name-based lookup with the 
> users/show
>  method
> to get the correct user id if necessary.


You will see from
http://api.twitter.com/users/show.json?screen_name=katie_walls that the
actual user id is 75030777.

Abraham

On Sun, Apr 11, 2010 at 12:07, ryan baldwin  wrote:

> Hey all, I've noticed some very odd and inconsistent behaviour over
> the past couple days that has me stumped.  When I use the users/show
> endpoint using user_id the response produces a 404. When I use
> screen_name of that same user everything works fine. Anybody know what
> the scoop is?
>
> here are a couple of examples:
> {
>  u'iso_language_code':u'en',
>  u'text':u'Twittering from the eye doctors office. Its kinda
> really boring here',
>  u'created_at':u'Sat,
>  10  Apr 2010 16:20:50  +',
>  u'profile_image_url':  u'http://a3.twimg.com/profile_images/
> 770801237/CIMG5940_normal.JPG',
>  u'source':  u' rel="nofollow">UberTwitter',
>  u'location':  u'ÜT:52.138437,
>  -106.667903  ', u'  from_user':u'katie_walls',
>  u'from_user_id':53548499,
>  u'to_user_id':None,
>  u'geo':None,
>  u'id':11944382350  L,
>  u'metadata':{
> u'result_type':u'recent'
>  }
>
> http://api.twitter.com/users/show.json?user_id=53548499 (404)
> http://api.twitter.com/users/show.json?screen_name=katie_walls (200,
> works fine)
>
> Any ideas? I'm at a complete loss and I'm really not looking forward
> to the repair costs of the hole I've made in the wall with the top of
> my head.
>
> Thanks!
>
> - ryan.
>
>
> --
> To unsubscribe, reply using "remove me" as the subject.
>



-- 
Abraham Williams | Developer for hire | http://abrah.am
PoseurTech Labs | Projects | http://labs.poseurtech.com
This email is: [ ] shareable [x] ask first [ ] private.

[twitter-dev] users/show raises 404 when using user_id; works fine for screen_name

[ryan baldwin]

Hey all, I've noticed some very odd and inconsistent behaviour over
the past couple days that has me stumped.  When I use the users/show
endpoint using user_id the response produces a 404. When I use
screen_name of that same user everything works fine. Anybody know what
the scoop is?

here are a couple of examples:
{
  u'iso_language_code':u'en',
  u'text':u'Twittering from the eye doctors office. Its kinda
really boring here',
  u'created_at':u'Sat,
  10  Apr 2010 16:20:50  +',
  u'profile_image_url':  u'http://a3.twimg.com/profile_images/
770801237/CIMG5940_normal.JPG',
  u'source':  u'UberTwitter',
  u'location':  u'ÜT:52.138437,
  -106.667903  ', u'  from_user':u'katie_walls',
  u'from_user_id':53548499,
  u'to_user_id':None,
  u'geo':None,
  u'id':11944382350  L,
  u'metadata':{
 u'result_type':u'recent'
  }

http://api.twitter.com/users/show.json?user_id=53548499 (404)
http://api.twitter.com/users/show.json?screen_name=katie_walls (200,
works fine)

Any ideas? I'm at a complete loss and I'm really not looking forward
to the repair costs of the hole I've made in the wall with the top of
my head.

Thanks!

- ryan.


-- 
To unsubscribe, reply using "remove me" as the subject.

[twitter-dev] Re: Twitter API - users/search - Help Required

[Jimmy]

Raffi and Nic, thanks for replying :)

Yes, I'm concerned with the user search and by mistake I wrote "ipad",
I should have written some name!

Now  please let me know whether the result should be changed or I'll
keep getting the stale result. I reckon twitter keep

getting new users every next minute then why API returns the same old
result and that is also to some extend.

Does API result change ?



On Apr 11, 5:28 pm, Nic Ross  wrote:
> Ok don't take it here an example for "ipad" may be it was his
> mistake.
>
> Lets say take an example for any common names like "James" or "Chang"
> or "Chen" don't you expect there will be far more results than 1000
> So, the point he is making here is will twitter keep the same result
> of 1000 users for every an authenticated user for any particular time
> duration or unlimitedly ?
>
> I think Jimmy can put some more light on the issue :)
>
> On Apr 11, 10:15 pm, Raffi Krikorian  wrote:
>
>
>
> > Well, with name search the users are not going to change much.  How  
> > many users do you expect to have the name "ipad" (even with the rate  
> > that users are being created).
>
> > Am I confused?
>
> > On Apr 11, 2010, at 1:01 PM, Nic Ross  wrote:
>
> > > Sorry I didn't see my last reply so I am posting it again
>
> > > @Raffi Krikorian
>
> > > I think Jimmy is asking for searching users not tweets. Look at his
> > > URLs they contain "users/search" and also "users/search" API call
> > > limits the result to 1000 (20
> > > result each page) which he is mentioning.
>
> > > The search API which you are suggestion is used to search Tweets not
> > > users.
>
> > > Regards
> > > Nic
>
> > > On Apr 11, 9:39 pm, Raffi Krikorian  wrote:
> > >> do you mean to be using "name search", or the general search API?  
> > >> Try
> > >> using the search endpoint at search.twitter.con.
>
> > >> On Apr 11, 2010, at 11:48 AM, Jimmy  wrote:
>
> > >>> Hi,
>
> > >>> I'm working on search api and and came across a problem. Here is my
> > >>> query:
>
> > >>>http://api.twitter.com/1/users/search.json?q=ipad&page=1
>
> > >>> The result which I got is constant and never changes. I checked the
> > >>> result after some span of time like: after 1-2 hours  but I got the
> > >>> same result.
>
> > >>> As per API we can only retrieve first 1000 matches in 50 pages(20
> > >>> result each page) so does it mean that for life long I will keep
> > >>> getting the same result for the same query? I mean that is weird!
>
> > >>> I also matched the result of second and third page
>
> > >>>http://api.twitter.com/1/users/search.json?q=ipad&page=2
> > >>>http://api.twitter.com/1/users/search.json?q=ipad&page=3
>
> > >>> within the span of 1-2 hours but the result was same each time.
>
> > >>> Any kind of help will be appreciatable.
>
> > >>> --
> > >>> To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Re: Upcoming changes to the way status IDs are sequenced

[John Kalucki]

If you are writing a general purpose display app, I think, (but I am not at
all certain), that you can ignore this issue. Reasonable polling frequency
on modest velocity timelines will sometimes, but very rarely, miss a tweet.
Also, over time, we're doing things to make this better for everyone. Many
of our projects have the side-effect of reducing K, decreasing the already
low since_id failure odds even further. Some tweet pipeline changes when
live in the last few weeks that dramatically reduce the K distribution for
various user types.

Since I don't know how the Last-Modified time exactly works, I'm going to
restate your response slightly:

Assuming synchronized clocks (or solely the Twitter Clock, if exposed
properly via Last-Modified), given a poll at time t, the newest status is at
least t - n seconds old, and sufficient n, then even a naive since_id
algorithm will be effectively Exactly Once. Assuming that Twitter is running
normally. For a given poll, when the poll time and last update time delta
drops below this n second period, there's a non-zero loss risk.

Just what is n? It is K expressed as time rather than as a discrete count.
For some timelines types, with some classes of users, K is as much as
perhaps 180 seconds. For others, K is less than 1 second. There's some
variability here that we should characterize more carefully internally and
then discuss publicly. I suspect there's a lot to be learned from this
exercise.

Since_id really runs into trouble when any of the following are too great:
the polling frequency, the updating frequency, the roughly-sorted K value.
If you are polling often to reduce display latency, use the Streaming API.
If the timeline moves too fast to capture it all exactly, you should
reconsider your requirements or get a Commercial Data License for the
Streaming API. Does the user really need to see every Bieber at 3 Biebers
Per Second? How would they ever know if they missed 10^-5 of them in a blur?
If you need them all for analysis, consider calculating the confidence
interval given a sample proportion of 1 - 10^6 (6 9s) or so vs. a total
enumeration. Indistinguishable. If you need them for some other purpose, say
CRM, the Streaming API may be the answer.

-John Kalucki
http://twitter.com/jkalucki
Infrastructure, Twitter Inc.


On Fri, Apr 9, 2010 at 2:28 PM, Brian Smith  wrote:

> John,
>
>
>
> I am not polling. I am simply trying to implement a basic “refresh” feature
> like every desktop/mobile Twitter app has. Basically, I just want to let
> users scroll through their timelines, and be reasonably sure that I am
> presenting them with an accurate & complete view of the timeline, while
> using as little bandwidth as possible.
>
>
>
> When I said “10 seconds old”/“30 seconds old”/etc. I was referring to I was
> referring to the age at the time the page of tweets was generated. So,
> basically, if the tweet’s timestamp – the response’s Last-Modified time more
> than 10,000 ms (from what you said below), you are almost definitely getting
> At Least Once behavior if Twitter is operating normally, and you can use
> that information to get At Least Once behavior that emulates Exactly Once
> behavior with little (usually no) overhead. Is that a correct interpretation
> of what you were saying?
>
>
>
> Thanks,
>
> Brian
>
>
>
>
>
> *From:* twitter-development-talk@googlegroups.com [mailto:
> twitter-development-t...@googlegroups.com] *On Behalf Of *John Kalucki
> *Sent:* Friday, April 09, 2010 3:31 PM
>
> *To:* twitter-development-talk@googlegroups.com
> *Subject:* Re: [twitter-dev] Re: Upcoming changes to the way status IDs
> are sequenced
>
>
>
> Your second paragraph doesn't quite make sense. The period between your
> next poll and the timestamp of the last status is irrelevant. The issue is
> solely the magnitude of K on the roughly sorted stream of events that are
> applied to the materialized timeline vector. As K varies, so do the odds,
> however infinitesimally small, that you will miss a tweet using the last
> status id returned. The period between your polls of the API does not affect
> this K.
>
> My recommendation is to ignore this issue in nearly every use case. If you
> are, however, polling high velocity timelines (including search queries) and
> attempting to approximate an Exactly Once QoS, you should, basically, stop
> doing that. You are probably wasting resources and you'll probably never get
> Exactly Once behavior anyway. Use the Streaming API instead.
>
> -John Kalucki
> http://twitter.com/jkalucki
> Infrastructure, Twitter Inc.
>
> On Fri, Apr 9, 2010 at 12:20 PM, Brian Smith  wrote:
>
> John,
>
>
>
> Thank you. That was one of the most informative emails on the Twitter API I
> have seen on the list.
>
>
>
> Basically, even now, an application should not use an ID of a tweet for
> since_id if the tweet is less than 10 seconds old, ignoring service
> abnormalities. Probably a larger threshold (30 seconds or even a minute)
> would be better, especia

[twitter-dev] TwitterConnect - xAuth and status update for iPhone, iPad, Cocoa (touch)

[Yves Vogl]

Hi,

I needed a solution to simply post status updates to Twitter from an iPhone 
app.  Just the typical stuff customers like to ask for: „Hey, can ya make our 
app post some stuff to Twitter, please?“.

Using xAuth was obvious because of usability concerns – everything else would 
just be like a crutch. So I started with Aral Balkan's xAuthTwitterEngine 
(http://aralbalkan.com/3133) but it seems that it has issues with special 
characters (e.g. a "+"). So I just took a look around and found a lot of 
similiar approaches which unfortunately ended up with the same issue because 
they were wrapping the same  underlying libraries.

Instead of fixing, compiling and coupling all those libraries out there I 
decided to start from scratch. There were some very well designed and great 
libraries (like Jon Crosby’s OAuthConsumer Framework) so that I could hardly 
imagine how to make it any better – therefore I adapted, rewrote or slighly 
modified parts of them whenever the license or author gave me permission to do 
this. Please see Credits section for details. If someones feels 
underappreciated, please don’t hesitate to contact me.

There's a lot of stuff to do… but posting a message to Twitter and displaying 
an xAuth view already works. Please see the wiki for further information: 
http://wiki.github.com/yves-vogl/TwitterConnect/
Help and bug reports are appreciated.

To project may be downloaded here: http://github.com/yves-vogl/TwitterConnect

Thanks for reading,

Yves



-- 
To unsubscribe, reply using "remove me" as the subject.

[twitter-dev] Re: Introduce yourself!

[46Bit]

I'm Michael Mokrysz, aka @46Bit.

I'm still a Student in real life, though I do a small amount of Web
Development (PHP, HTML, Javascript) to earn some money doing what I
enjoy. I've been messing around with the API for months mostly out of
interest and because the clients I make webapps for from time to time
like to include a basic login integration or the like. I've been
hanging around this group for a while, but I've only got round to
signing up to post now.


-- 
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Re: Twitter buying Tweetie

[46Bit]

Nigel Legg wrote:
> Dewalt, surely it's a bit early to say they are kaput? As far as I can see,
> all twitter clients have their merits, and people tend to stick with the one
> that does what they want it to do in the way they want it to do it.  I find
> it odd that, even though twitter has been directly competing with twitter
> clients through it's website for as long as the API has been around, the
> fact of twitter buying out a client means clients are dead.  Personally, I
> think you have over reacted to this.

Whilst it's fair to say that people broadly stick with what they've
got, any ordinary user that is using a different twitter-only client
is quite likely to hear about this and look into the official app, and
any new users/people just getting an iphone will immediately spring
for the official app. Why? It's *free*, it's got loads of publicity,
it's well known as a good app in it's former Tweetie form, and in
developing it using new API features (even presuming it's kept to use
of the public APIs) before they are announced it will have a very
major head start as compared to apps made by anyone else.

Whilst yes free apps may well survive this by virtue of being free,
there's little chance of them growing much in user counts, or being
able to put ads on to get some payoff from their hard work unless
Twitter does with ex-Tweetie (which whilst not impossible I'd say is
perhaps unlikely) since ads would detract from the UX and so
potentially push people towards Twitter's client.

Having said all that though, I have to say that realistically this is
what you have to be prepared for when working with third-party
services - iPhone, Android, Twitter, Facebook, etc etc all have the
same weakness: if the company takes a fancy to your competitor, or
clones your functionality, then you're likely toast.


-- 
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Twitter Streaming + Geo = 4square Vision

[znmeb]

- "Raffi Krikorian"  wrote:

> We could just be running JavaScript in V8, for all you know :p

Yeah ... and if I didn't have half a dozen other hobbies, I'd write an R 
language engine for the Java Virtual Machine that would run the pants off the 
native one. ;-)

--
M. Edward (Ed) Borasky
http://borasky-research.net/m-edward-ed-borasky/ @znmeb

"A mathematician is a device for turning coffee into theorems." ~  Paul Erdős


-- 
To unsubscribe, reply using "remove me" as the subject.

[twitter-dev] Re: Twitter API - users/search - Help Required

[Nic Ross]

Ok don't take it here an example for "ipad" may be it was his
mistake.

Lets say take an example for any common names like "James" or "Chang"
or "Chen" don't you expect there will be far more results than 1000
So, the point he is making here is will twitter keep the same result
of 1000 users for every an authenticated user for any particular time
duration or unlimitedly ?

I think Jimmy can put some more light on the issue :)

On Apr 11, 10:15 pm, Raffi Krikorian  wrote:
> Well, with name search the users are not going to change much.  How  
> many users do you expect to have the name "ipad" (even with the rate  
> that users are being created).
>
> Am I confused?
>
> On Apr 11, 2010, at 1:01 PM, Nic Ross  wrote:
>
> > Sorry I didn't see my last reply so I am posting it again
>
> > @Raffi Krikorian
>
> > I think Jimmy is asking for searching users not tweets. Look at his
> > URLs they contain "users/search" and also "users/search" API call
> > limits the result to 1000 (20
> > result each page) which he is mentioning.
>
> > The search API which you are suggestion is used to search Tweets not
> > users.
>
> > Regards
> > Nic
>
> > On Apr 11, 9:39 pm, Raffi Krikorian  wrote:
> >> do you mean to be using "name search", or the general search API?  
> >> Try
> >> using the search endpoint at search.twitter.con.
>
> >> On Apr 11, 2010, at 11:48 AM, Jimmy  wrote:
>
> >>> Hi,
>
> >>> I'm working on search api and and came across a problem. Here is my
> >>> query:
>
> >>>http://api.twitter.com/1/users/search.json?q=ipad&page=1
>
> >>> The result which I got is constant and never changes. I checked the
> >>> result after some span of time like: after 1-2 hours  but I got the
> >>> same result.
>
> >>> As per API we can only retrieve first 1000 matches in 50 pages(20
> >>> result each page) so does it mean that for life long I will keep
> >>> getting the same result for the same query? I mean that is weird!
>
> >>> I also matched the result of second and third page
>
> >>>http://api.twitter.com/1/users/search.json?q=ipad&page=2
> >>>http://api.twitter.com/1/users/search.json?q=ipad&page=3
>
> >>> within the span of 1-2 hours but the result was same each time.
>
> >>> Any kind of help will be appreciatable.
>
> >>> --
> >>> To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Twitter Streaming + Geo = 4square Vision

[Raffi Krikorian]

We could just be running JavaScript in V8, for all you know :p



On Apr 11, 2010, at 1:15 PM, zn...@comcast.net wrote:



- "Chad Etzel"  wrote:


Nice username grab, raffi!

Also, nice lib. I wonder what awesome thing this could be used for
testing... :)

I'm doing a significant bit of stream pre-processing on the backend
before pushing stuff to the browser (it would probably crush most
non-chrome browsers to do it all in javascript), plus the whole
user/pass thing... but this will definitely be useful for testing
other streams in the future.

-Chad


You guys are going to force me to break down and learn JavaScript!  
Well, you and the folks that are making server-side JavaScript  
efficient. ;-) One language to rule them all? Finally?


Oh, wait - Scala. Is there browser-side Scala? ;-)
--
M. Edward (Ed) Borasky
http://borasky-research.net/m-edward-ed-borasky/ @znmeb

"A mathematician is a device for turning coffee into theorems." ~  
Paul Erdős



--
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Re: Twitter API - users/search - Help Required

[Raffi Krikorian]

Well, with name search the users are not going to change much.  How  
many users do you expect to have the name "ipad" (even with the rate  
that users are being created).


Am I confused?



On Apr 11, 2010, at 1:01 PM, Nic Ross  wrote:


Sorry I didn't see my last reply so I am posting it again

@Raffi Krikorian

I think Jimmy is asking for searching users not tweets. Look at his
URLs they contain "users/search" and also "users/search" API call
limits the result to 1000 (20
result each page) which he is mentioning.

The search API which you are suggestion is used to search Tweets not
users.


Regards
Nic

On Apr 11, 9:39 pm, Raffi Krikorian  wrote:
do you mean to be using "name search", or the general search API?   
Try

using the search endpoint at search.twitter.con.

On Apr 11, 2010, at 11:48 AM, Jimmy  wrote:


Hi,



I'm working on search api and and came across a problem. Here is my
query:



http://api.twitter.com/1/users/search.json?q=ipad&page=1



The result which I got is constant and never changes. I checked the
result after some span of time like: after 1-2 hours  but I got the
same result.



As per API we can only retrieve first 1000 matches in 50 pages(20
result each page) so does it mean that for life long I will keep
getting the same result for the same query? I mean that is weird!



I also matched the result of second and third page



http://api.twitter.com/1/users/search.json?q=ipad&page=2
http://api.twitter.com/1/users/search.json?q=ipad&page=3



within the span of 1-2 hours but the result was same each time.



Any kind of help will be appreciatable.



--
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Twitter Streaming + Geo = 4square Vision

[znmeb]

- "Chad Etzel"  wrote:

> Nice username grab, raffi!
> 
> Also, nice lib. I wonder what awesome thing this could be used for
> testing... :)
> 
> I'm doing a significant bit of stream pre-processing on the backend
> before pushing stuff to the browser (it would probably crush most
> non-chrome browsers to do it all in javascript), plus the whole
> user/pass thing... but this will definitely be useful for testing
> other streams in the future.
> 
> -Chad

You guys are going to force me to break down and learn JavaScript! Well, you 
and the folks that are making server-side JavaScript efficient. ;-) One 
language to rule them all? Finally?

Oh, wait - Scala. Is there browser-side Scala? ;-)
--
M. Edward (Ed) Borasky
http://borasky-research.net/m-edward-ed-borasky/ @znmeb

"A mathematician is a device for turning coffee into theorems." ~ Paul Erdős


-- 
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Is it safe to authenticate and send requests via OAuth using Javascript

[Cameron Kaiser]

> We are doing all we can to get it done before basic auth removal.  I  
> suspect if the spec is not finalized soon, we will just move forward  
> with a draft spec.

Can you send me that draft URL? I'd like to see how much change will be
needed (I expect not a great deal).

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- Look busy. Jesus is coming soon. ---

[twitter-dev] Re: Twitter API - users/search - Help Required

[Nic Ross]

Sorry I didn't see my last reply so I am posting it again

@Raffi Krikorian

I think Jimmy is asking for searching users not tweets. Look at his
URLs they contain "users/search" and also "users/search" API call
limits the result to 1000 (20
result each page) which he is mentioning.

The search API which you are suggestion is used to search Tweets not
users.


Regards
Nic

On Apr 11, 9:39 pm, Raffi Krikorian  wrote:
> do you mean to be using "name search", or the general search API?  Try  
> using the search endpoint at search.twitter.con.
>
> On Apr 11, 2010, at 11:48 AM, Jimmy  wrote:
>
> > Hi,
>
> > I'm working on search api and and came across a problem. Here is my
> > query:
>
> >http://api.twitter.com/1/users/search.json?q=ipad&page=1
>
> > The result which I got is constant and never changes. I checked the
> > result after some span of time like: after 1-2 hours  but I got the
> > same result.
>
> > As per API we can only retrieve first 1000 matches in 50 pages(20
> > result each page) so does it mean that for life long I will keep
> > getting the same result for the same query? I mean that is weird!
>
> > I also matched the result of second and third page
>
> >http://api.twitter.com/1/users/search.json?q=ipad&page=2
> >http://api.twitter.com/1/users/search.json?q=ipad&page=3
>
> > within the span of 1-2 hours but the result was same each time.
>
> > Any kind of help will be appreciatable.
>
> > --
> > To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Is it safe to authenticate and send requests via OAuth using Javascript

[Raffi Krikorian]

We are doing all we can to get it done before basic auth removal.  I  
suspect if the spec is not finalized soon, we will just move forward  
with a draft spec.




On Apr 11, 2010, at 12:06 PM, Cameron Kaiser   
wrote:



just to follow up on this, we're working on an oauth 2.0
implementation (of which we are contributors/authors to the spec).
that does have a profile which makes it possible to write JavaScript
oauth clients without compromising the keys.  I can't give a date  
yet,

however, as the spec is not even finalized yet.  if people are
interested, I can circulate a URL to the draft.


However, if that does not occur prior to the Basic Auth drop-dead  
date, then
there will have to be some measure of 'key compromise' in open  
source clients.
Currently I have no choice but to minimally obfuscate my secret in  
TTYtter,
while documenting I know full well it will be trivially easy to  
recover (or
have the user create their own xAuth-enabled key/secret pair, which  
I'm sure

many users will balk at).

--
 personal: http://www.cameronkaiser.com/ 
 --

 Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- I use my C128 because I am an ornery, stubborn, retro grouch. --  
Bob Masse -



--
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Twitter API - users/search - Help Required

[Raffi Krikorian]

do you mean to be using "name search", or the general search API?  Try  
using the search endpoint at search.twitter.con.




On Apr 11, 2010, at 11:48 AM, Jimmy  wrote:


Hi,

I'm working on search api and and came across a problem. Here is my
query:

http://api.twitter.com/1/users/search.json?q=ipad&page=1

The result which I got is constant and never changes. I checked the
result after some span of time like: after 1-2 hours  but I got the
same result.

As per API we can only retrieve first 1000 matches in 50 pages(20
result each page) so does it mean that for life long I will keep
getting the same result for the same query? I mean that is weird!


I also matched the result of second and third page

http://api.twitter.com/1/users/search.json?q=ipad&page=2
http://api.twitter.com/1/users/search.json?q=ipad&page=3

within the span of 1-2 hours but the result was same each time.


Any kind of help will be appreciatable.


--
To unsubscribe, reply using "remove me" as the subject.

[twitter-dev] Re: Bulk User Relationship Lookup?

[Orian Marx (@orian)]

Sorry, late night stupidity was in effect. I was sending up message
ids instead of message sender ids :-) It's all working great.

On Apr 11, 6:35 am, Raffi Krikorian  wrote:
> really?  that's interesting.  i have tests for it working in oauth  can
> you send me details, please?
>
> On Sun, Apr 11, 2010 at 12:38 AM, Orian Marx (@orian)
> wrote:
>
>
>
>
>
> > Also, does this endpoint support oauth? I seem to be having trouble
> > making an oauth request to it vs basic-auth.
>
> > On Apr 9, 12:17 pm, Raffi Krikorian  wrote:
> > > at the risk of introducing features instead of fixing bugs, this endpoint
> > > may also be of use -- its a work in progress, and a few details of it may
> > > change:
>
> > >http://api.twitter.com/1/friendships/lookup.xml?user_id=813286,783214
>
> > > On Wed, Mar 31, 2010 at 8:02 AM, Orian Marx (@orian) <
> > or...@orianmarx.com>wrote:
>
> > > > I would certainly be interested in such a list, but no I don't think
> > > > Twitter will be providing one.
>
> > > > On Mar 30, 9:26 pm, mcfnord  wrote:
> > > > > Hi, Abraham, and everyone.
>
> > > > > I'm crawling twitter. (But who isn't, right?) Us social graph geeks
> > > > > have our own advantages, and our own set of challenges.
> > > > > For example, I would not want to manage the vastness of tweet
> > volumes.
> > > > > But I do get neck-deep in social graph data. Which means I crawl with
> > > > > this:http://twitter.com/friends/ids.xml/?user_id=12345
> > > > > x20,000/hr.
> > > > > so far i've discovered existance of 51 million accounts, and examined
> > > > > 13 million of these. if i need two scrapes to determine account
> > > > > activity, then i've got just 89 million captures to go! that's 6
> > > > > months at full speed.
>
> > > > > inactive accounts can live with a vastly slower refresh cycle.
> > > > > so really what would benefit me (and twitter, as i see it) is a cheat
> > > > > sheet of active vs. inactive accounts.
> > > > > download the file, and know the integers within it are active
> > > > > accounts.
>
> > > > > in one move, through occasional publication of one file, twitter
> > saves
> > > > > 6 months of scrapes for anyone who can leverage a quick-start list of
> > > > > which accounts are active, and which are inactive. i imagine people
> > > > > could, in many scenarios, limit their entire set of inquiries to
> > these
> > > > > active accounts, saving millions of calls to twitter's api.
>
> > > > > maybe it's bad p.r. to state explicitly which accounts merit
> > resources
> > > > > and which are dead.
>
> > > > > i guess once it's over i won't look back and perhaps it is i who can
> > > > > publish this dataset to some other newbie. but what a great
> > efficiency
> > > > > for twitter to avoid this for everyone in my shoes. which are small
> > > > > shoes, i accept.
>
> > > > > best regards,
> > > > > john
>
> > > > > On Mar 23, 11:56 am, Abraham Williams <4bra...@gmail.com> wrote:
>
> > > > > > Bulk lookup of social graphs seems like it would be a pretty
> > resource
> > > > > > intensive call. I would not hold my breath for Twitter to implement
> > it.
>
> > > > > > Abraham
>
> > > > > > On Tue, Mar 23, 2010 at 08:21,OrianMarx (@orian) <
> > or...@orianmarx.com
> > > > >wrote:
>
> > > > > > > Thanks Abraham, don't worry I'm watching Intersect closely ;)
>
> > > > > > > Unfortunately, this doesn't currently address what I'm getting
> > at,
> > > > > > > namely, if I use the bulk user lookup, I'd like to similarly get
> > > > > > > accurate friend / follower info for each of those users (relative
> > to
> > > > > > > the user making the bulk lookup) in one call.
>
> > > > > > > On Mar 22, 11:00 pm, Abraham Williams <4bra...@gmail.com> wrote:
> > > > > > > > I provide a simple API that returns common friends and follower
> > of
> > > > two
> > > > > > > > specific Twitter users. It currently works for the 5000 most
> > recent
> > > > > > > > (although soon to be increasing) and only on public accounts.
>
> > > > > > > >http://github.com/abraham/intersect/blob/master/README
>
> > > > > > > >  > >Abraham
>
> > > > > > > > On Mon, Mar 22, 2010 at 19:41,OrianMarx (@orian) <
> > > > or...@orianmarx.com
> > > > > > > >wrote:
>
> > > > > > > > > The bulk users/lookup call recently added to the API is a
> > great
> > > > new
> > > > > > > > > tool for developers. This call would become even more useful
> > with
> > > > a
> > > > > > > > > corresponding bulk lookup for user relationships. Are there
> > any
> > > > plans
> > > > > > > > > for this?
>
> > > > > > > > > Also, I'm assuming that the  and 
> > nodes
> > > > > > > > > returned in the user objects of the users/lookup call should
> > be
> > > > > > > > > considered unreliable as is stated for users/show.
>
> > > > > > > > > Thanks,
> > > > > > > > > @orian
>
> > > > > > > > > To unsubscribe from this group, send email to
> > > > twitter-development-talk+
> > > > > > > > > unsubscribegooglegroups.co

Re: [twitter-dev] Is it safe to authenticate and send requests via OAuth using Javascript

[Cameron Kaiser]

> just to follow up on this, we're working on an oauth 2.0  
> implementation (of which we are contributors/authors to the spec).   
> that does have a profile which makes it possible to write JavaScript  
> oauth clients without compromising the keys.  I can't give a date yet,  
> however, as the spec is not even finalized yet.  if people are  
> interested, I can circulate a URL to the draft.

However, if that does not occur prior to the Basic Auth drop-dead date, then
there will have to be some measure of 'key compromise' in open source clients.
Currently I have no choice but to minimally obfuscate my secret in TTYtter,
while documenting I know full well it will be trivially easy to recover (or
have the user create their own xAuth-enabled key/secret pair, which I'm sure
many users will balk at).

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- I use my C128 because I am an ornery, stubborn, retro grouch. -- Bob Masse -


-- 
To unsubscribe, reply using "remove me" as the subject.

[twitter-dev] Twitter API - users/search - Help Required

[Jimmy]

Hi,

I'm working on search api and and came across a problem. Here is my
query:

http://api.twitter.com/1/users/search.json?q=ipad&page=1

The result which I got is constant and never changes. I checked the
result after some span of time like: after 1-2 hours  but I got the
same result.

As per API we can only retrieve first 1000 matches in 50 pages(20
result each page) so does it mean that for life long I will keep
getting the same result for the same query? I mean that is weird!


I also matched the result of second and third page

http://api.twitter.com/1/users/search.json?q=ipad&page=2
http://api.twitter.com/1/users/search.json?q=ipad&page=3

within the span of 1-2 hours but the result was same each time.


Any kind of help will be appreciatable.


-- 
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Is it safe to authenticate and send requests via OAuth using Javascript

[Raffi Krikorian]

just to follow up on this, we're working on an oauth 2.0  
implementation (of which we are contributors/authors to the spec).   
that does have a profile which makes it possible to write JavaScript  
oauth clients without compromising the keys.  I can't give a date yet,  
however, as the spec is not even finalized yet.  if people are  
interested, I can circulate a URL to the draft.




On Apr 11, 2010, at 9:23 AM, Taylor Singletary > wrote:



Safe to send the requests, yes. Safe to sign them, no.

In pure Javascript OAuth 1.0A implementations, your consumer secret  
will have to appear somewhere in your Javascript code to sign the  
requests. The visibility of your secret compromises your API keys  
and requests, putting your application and user's reputations &  
security at risk. There's always a risk of secret discovery in  
desktop or pure client applications, but it's riskiest when the  
secret is in plain sight.


Taylor Singletary
Developer Advocate, Twitter
http://twitter.com/episod


On Sun, Apr 11, 2010 at 12:09 AM, Karolis  wrote:
Hello lively community,

I am in the process of building web app based on a Twitter Data.
Currently all my app is based on javascript and everything happens
client side.
However, due to API rate limitations and because some of the twitter
request have to be authenticated (users/lookup) - i have to use oauth
authentication.
Now my question is it safe to send api requests authenticated by OAUTH
via ajax calls which are happening on client side?

Thanks in advance
karolis


--
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Can an authorize URL pass through a parameter?

[Abraham Williams]

You can create a custom oauth_callback with your own parameters in your call
to get a request_token (temporary credentials) and Twitter is required by
spec to append oauth_token to it when your user returns from authorizing
access.

If the callback URI already includes a query component, the serverMUST
> append the OAuth parameters to the end of the existing query.


http://tools.ietf.org/html/draft-hammer-oauth-10#section-2.2

Abraham

On Sun, Apr 11, 2010 at 03:34, Raffi Krikorian  wrote:

> The specific one first. When I registered my application with Twitter, it
>> made me specify a callback URL. In fact, what page I want Twitter to "call
>> back" depends on what the user is doing! Consequently, the callback page
>> must figure out what the user was doing and redirect to one of several other
>> pages, as appropriate.
>>
>> That will be a lot easier if I can furnish the authorize URL with a
>> parameter that Twitter will return to the callback URL along with the token
>> that it provides. Is that possible?
>>
>
> i don't think this is possible in oauth 1.0a.  i know oauth 2.0 has a state
> parameter (don't quote me on the name) that will allow clients to pass an
> opaque string to the server who will then pass it back.
>
> --
> Raffi Krikorian
> Twitter Platform Team
> http://twitter.com/raffi
>



-- 
Abraham Williams | Developer for hire | http://abrah.am
PoseurTech Labs | Projects | http://labs.poseurtech.com
This email is: [ ] shareable [x] ask first [ ] private.


-- 
To unsubscribe, reply using "remove me" as the subject.

[twitter-dev] Re: Fred Wilson article on Twitter API

[Dewald Pretorius]

You are also free and welcome to express your opinions, even when
hiding behind a veil of anonymity.

On Apr 11, 9:03 am, notinfluential  wrote:
> Totally over-dramatic.  And way beyond annoying at this point.
>
> Dewald, quit your whining and either get back to coding and doing
> something productive, or maybe you should aim your posts at this group
> instead:http://groups.google.com/group/delusional-socialist-development-talk
>
> @notinfluential
>
> On Apr 10, 11:05 am, Raffi Krikorian  wrote:
>
>
>
> > > Twitter has now displayed a distinctive predatorial stance towards the
> > > developer ecosystem.
>
> > That's incredibly overdramatic, I think. We have, and continue to  
> > maintain a platform that will allow for a vibrant ecosystem.  We want  
> > everybody to succeed.- Hide quoted text -
>
> - Show quoted text -


-- 
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Is it safe to authenticate and send requests via OAuth using Javascript

[Taylor Singletary]

Safe to send the requests, yes. Safe to sign them, no.

In pure Javascript OAuth 1.0A implementations, your consumer secret will
have to appear somewhere in your Javascript code to sign the requests. The
visibility of your secret compromises your API keys and requests, putting
your application and user's reputations & security at risk. There's always a
risk of secret discovery in desktop or pure client applications, but it's
riskiest when the secret is in plain sight.

Taylor Singletary
Developer Advocate, Twitter
http://twitter.com/episod


On Sun, Apr 11, 2010 at 12:09 AM, Karolis  wrote:

> Hello lively community,
>
> I am in the process of building web app based on a Twitter Data.
> Currently all my app is based on javascript and everything happens
> client side.
> However, due to API rate limitations and because some of the twitter
> request have to be authenticated (users/lookup) - i have to use oauth
> authentication.
> Now my question is it safe to send api requests authenticated by OAUTH
> via ajax calls which are happening on client side?
>
> Thanks in advance
> karolis
>
>
> --
> To unsubscribe, reply using "remove me" as the subject.
>

[twitter-dev] Re: Fred Wilson article on Twitter API

[notinfluential]

Totally over-dramatic.  And way beyond annoying at this point.

Dewald, quit your whining and either get back to coding and doing
something productive, or maybe you should aim your posts at this group
instead:
http://groups.google.com/group/delusional-socialist-development-talk

@notinfluential


On Apr 10, 11:05 am, Raffi Krikorian  wrote:
> > Twitter has now displayed a distinctive predatorial stance towards the
> > developer ecosystem.
>
> That's incredibly overdramatic, I think. We have, and continue to  
> maintain a platform that will allow for a vibrant ecosystem.  We want  
> everybody to succeed.


-- 
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Re: Twitter buying Tweetie

[Nigel Legg]

My twitter client will be ready in about a month. I hope I have unique
enough features to survive.

On 11 April 2010 02:27, Arnaud Meunier wrote:

> +1 for the metaphors :)
>
> We all know what Twitter would like to see. No surprise here, nothing
> extraordinary, just advices we already were aware of. I mean... Who
> intended to code another photo sharing service or another desktop
> client before these annoucements? I guess nobody.
>
> Anybody who has been seriously thinking about starting a project
> around Twitter in the last year already knew he'd have to make
> something innovative enough to drag attention, customers, whatever
> he's looking for...
>
> In a word, there's nothing new with these annoucements and this
> acquisation. The only thing "new" is simply the fact that it's now
> "officially said". Quite annoying for all the "old school
> apps" (thinking to existing clients, analytics services, media sharing
> tools...) Even for some of the new one, by the way, as a part of the
> applications who's going to emerge will probably wonder "what if
> Twitter decides to make a product of my concept?"
>
> Inherent risk of a business based (even partly) on an existing
> platform? Yes!
>
> And the thing is I'm very curious to see how Twitter is going to deal
> with this at Chirp, and what (really new, this time) they're going to
> announce. For example, a smart monetization policy (around advertising
> or sponsored tweets) linked to the API could be an answer for most of
> the "old school apps".
>
> Arnaud - http://twitter.com/twitoaster
> Twitoaster - http://twitoaster.com
>
>
> Le 11 avr. 2010 à 01:04, "zn...@comcast.net"  a
> écrit :
>
> >
> > - "Jesse Stay"  wrote:
> >
> >> Why are you filling holes in Twitter? Why not rather create your own
> >> holes and use Twitter to fill them. When you own the dirt you have
> >> control over what grows in that dirt.
> >
> > I think we've pretty much exhausted the holes and dirt metaphor, and
> > I'd like to propose a different one. A business is defined by the
> > answer(s) to the question, "Who is going to sell what to whom?" So,
> > what are the needs of the Twitter "customer base?"
> >
> > Raffi has posted some things he'd like to see, and I read the blogs
> > regularly and have some clues as to what people like @scobleizer,
> > @mashable, etc. think Twitter should become. And it all boils down
> > to what real problems people have, what costs them money and time,
> > what they don't know that could hurt them, and so on. Once we know
> > what the problems are, how can the *Twitter* ecosystem solve them?
> >
> > @znmeb
>
>
> --
> To unsubscribe, reply using "remove me" as the subject.
>

Re: [twitter-dev] Re: Final Hack Day schedule for Chirp with discount code

[Nigel Legg]

I'd love to be there, but I have commitments here I can't get away from at
such short notice.  Damn. I'll follow on twitter, assuming people use it.
;-)


On 11 April 2010 02:23, funkatron  wrote:

> I actually would consider buying these tickets, but 5 days notice;
> that's not so good for non-locals.
>
> Thanks for trying to make it affordable to mailing list folks, tho.
>
> --
> Ed Finkler
> http://funkatron.com
> @funkatron
> AIM: funka7ron / ICQ: 3922133 / 
> XMPP:funkat...@gmail.com
>
>
> On Apr 10, 9:18 pm, Ryan Sarver  wrote:
> > Hey all,
> >
> > Wanted to let you know that we have finalized the schedule for Hack Day
> > sessions at Chirp. We're really excited about the content and would love
> to
> > have you there. Also, each session has a Google Moderator section setup
> so
> > you can get your questions in ahead of time. Be sure to add your
> questions
> > so the speakers know what to talk to:http://bit.ly/dbpnXZ
> >
> > Hack Day tickets are still available and we're providing a 50% discount
> for
> > the first 100 registrations from the mailing list. Please don't share
> this
> > outside of this listhttp://chirp.eventbrite.com/?discount=DEVTALK10
> >
> > Hopefully see you next week! Best, rs
> >
> > *Quick Agenda for Hack Day*
> > *Apr 14th*
> > - 6pm - Hack Day registration, dinner and drinks
> > - 8pm - Ignite Chirp hosted by Brady Forrest
> > - 9pm+ - Hacking for the night owls
> >
> > *Apr 15th*
> > - 8am - 10am - Registration and breakfast (Registration is open all day)
> > - 10am - Welcome with Ron Conway
> > - 10:15am - 5pm - Sessions start and go all day with a lunch you
> shouldn't
> > miss
> > - 5pm - App Showcase with Marissa Mayer, Paul Graham and Philip Kaplan.
> > Moderated by Jason Goldman (@goldman)
> > - 9pm - Chirp Party at 1015 Folsom
> >
> > *Hack Day Sessions*
> > *Twitter Streaming API Architecture and What's Next* #chirpstream with
> John
> > Kalucki
> > *Eating our own Dogfood: Designing Twitter Mobile Web* #chirpmobile with
> > Leland Rechis
> > *We Have Faith In (Most of) You: How Twitter Crafts Policies to Allow
> Good
> > Apps to Thrive* #chirppolicy with Del Harvey
> > *Office Hours: Twitter Platform Team* with Ryan Sarver, Doug Williams,
> Raffi
> > Krikorian, Mark McBride, Dana Contreras, Isaac Hepworth, Marcel Molina,
> > Taylor Singletary, Todd Kloots, Wilhelm Bierbaum
> > *Office Hours: Design/UX *with Doug Bowman, Zhanna Shamis, Britt
> Selvitelle,
> > Patrck Ewing, Mark Trammel, Vitor Lourenço, Mark Otto, Coleen Baik
> >
> > *Integrating @anywhere* #chirpanywhere with Todd Kloots, Dustin Diaz, Dan
> > Webb, Russ D'Sa
> > *Effective Use of the Twitter Search API *#chirpsearch with Eric Jensen
> > *Analyzing Big Data at Twitter* #chirpdata with Kevin Weil
> > *Office Hours: Working at Twitter* @jointheflock with Oliver Ryan,
> > Bernadette Coh, Jamie Narva, Michelle Gale, Morgan Missentzis, Olivia
> > Watkins
> > *Office Hours: The Electronic Frontier Foundation* with Marcia Hofmann,
> Kurt
> > Opsahl, Cindy Cohn, Fred von Lohmann
> >
> > *Twitter, Media, and Kanye's Exploding Head* #chirpmedia with Chloe
> Sladden,
> > Robin Sloan
> > *Too many secrets, but never enough: Twitter OAuth *#chirpoauth with
> Taylor
> > Singletary, Raffi Krikorian
> > *Changing Engines Mid-flight: Moving Twitter from MySQL to
> > Cassandra*#chirpcassandra with Ryan King
> > *Birds of a Feather: Real-Time Search* with Doug Cook
> > *Office Hours: Trademark Policy and Branding Guidelines *with Jillian
> West,
> > Jeremy Kessel, Francesca Helena, Tim Yip, Bakari Brock
> >
> > *The How and Why of Scala at Twitter* #chirpscala with Alex Payne
> > *"What's happening?" to "What's happening here?"* #chirpgeo with Raffi
> > Krikorian
> > *Thinking in Streams: Patterns for Stream Processing* #chirpstream with
> John
> > Kalucki
> > *Meet and Greet: Founders* with Evan Williams and Biz Stone
> > *Office Hours: Twitter Corp and Business Development* with Elizabeth
> Weil,
> > Doug Williams, Isaac Hepworth, Bakari Brock, Jessica Verrilli
> >
> > *Billions of Hits: Scaling Twitter* #chirpscale with John Adams
> > *Twitter International* #chirpintl with Matt Sanford
> > *All Aboard? Turning Users into Active Users* #chirponboard with Josh
> Elman
> > *Meet and Greet: Funding* with David Cohen, Paul Graham, Ron Conway
> > *Birds of a Feather: Media Curation* with Chloe Sladden and Robin Sloan
>
>
> --
> To unsubscribe, reply using "remove me" as the subject.
>

[twitter-dev] Is it safe to authenticate and send requests via OAuth using Javascript

[Karolis]

Hello lively community,

I am in the process of building web app based on a Twitter Data.
Currently all my app is based on javascript and everything happens
client side.
However, due to API rate limitations and because some of the twitter
request have to be authenticated (users/lookup) - i have to use oauth
authentication.
Now my question is it safe to send api requests authenticated by OAUTH
via ajax calls which are happening on client side?

Thanks in advance
karolis


-- 
To unsubscribe, reply using "remove me" as the subject.

[twitter-dev] Re: Twitter buying Tweetie

[Dewald Pretorius]

LMAO. No thanks. I'm getting a little too old for dodging eggs and
tomatoes.

On second thoughts, I could toss a mean salad if I just remember to
bring the lettuce.

On Apr 11, 3:23 am, PJB  wrote:
> +1 for Dewald getting his own session at Chirp! ;)  (Seriously!)
>
> On Apr 10, 2:49 pm, Dewald Pretorius  wrote:
>
>
>
> > Maybe it's because I'm of the older generation, have been there and
> > done that, and have discovered that the top looks so green because of
> > all the crap that lies and flies there, that I hold the opinions that
> > I do.
>
> > I can understand folks' ambitions to "make" it. I guess in a way it's
> > like a green recruit versus a veteran soldier. When you ask a green
> > recruit about war, you will get answers about glorious deeds, killing
> > the evil enemy, the honor of dying for your country, great adventure,
> > and the like. When you ask a veteran soldier about war, you will get
> > answers about rotting corpses, pieces of human meat splattered
> > everywhere, being shit scared, losing your best buddies, and fighting
> > and taking risks only to protect your buddies.
>
> > Someone couldn't pay me enough to be at the "top". The lifestyle is
> > not worth the other sacrifices you need to make.
>
> > On Apr 10, 6:25 pm, Dewald Pretorius  wrote:
>
> > > Chad,
>
> > > Sometimes (well, okay, almost always) I just don't feel like citing
> > > all possible caveats to what I'm saying. I'm not writing here with
> > > visions of possible literary grandeur, potential book deals, or
> > > speaking engagements. I call shit like I see it. Sometimes I'm right,
> > > sometimes I'm wrong. It's just my opinion. Don't take what I say as
> > > gospel.
>
> > > Yes, there are ethical investors too. But, when the entrepeneur's
> > > ethics clash with the investor's ethics, or lack thereof, guess who is
> > > going to win. It does not require board level action or majority vote
> > > to put pressure on an entrepreneur. Simple verbal threats regarding
> > > current and future investments often suffice.
>
> > > On Apr 10, 6:13 pm, Chad Etzel  wrote:
>
> > > > On Sat, Apr 10, 2010 at 1:21 PM, Dewald Pretorius  
> > > > wrote:
> > > > > If you're an entrpreneur with strong ethical standards, then never
> > > > > ever accept investment capital.
>
> > > > You cannot be serious.
>
> > > > Believe it or not there are ethical investors out there. Also,
> > > > bootstrapping a company that goes huge is almost impossible,
> > > > especially for the younger entrepreneurial crowd that can afford the
> > > > time and lifestyle that it would entail but probably does not have
> > > > tons of cash in the bank. Can you please site such a company that
> > > > received zero outside investment dollars?
>
> > > > -Chad- Hide quoted text -
>
> > > - Show quoted text -


-- 
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] open source twitter-text

[Patrick Kennedy]

Actually, I can make it work like this -

require 'rubygems'
require 'lib/extractor'
require 'lib/regex'

include Twitter::Extractor
usernames = extract_mentioned_screen_names("Mentioning @twitter and @jack")
puts usernames
# usernames = ["twitter", "jack"]

But I want to use classes like this -

require 'rubygems'
require 'unicode'
$KCODE = 'KU'
require 'twitter-text'

class MyClass
include Twitter::Extractor
usernames = extract_mentioned_screen_names("Mentioning @twitter and @jack")
puts usernames
end

m = MyClass.new



On Sun, Apr 11, 2010 at 5:37 PM, Patrick  wrote:
>
> The twitter open source code looks simple and fun -
>
> http://github.com/mzsanford/twitter-text-rb
>
> However, it seems I need to install unicode support.  On Linux, I was
> able to, though on Windows 7, I don't have nmake (don't have C++).
> Anyways, it still complains about setting $KCODE to utf8 or u (or
> using the -KU command line switch).  I tried both but can't seem to
> make it work.  Which gem do I need for unicode, and how can I set it
> programmatically?
>
> I tried ideas like this:
>
> require 'rubygems'
> require 'unicode'
> $KCODE = 'KU'
>
>
> --
> To unsubscribe, reply using "remove me" as the subject.
>

[twitter-dev] open source twitter-text

[Patrick]

The twitter open source code looks simple and fun -

http://github.com/mzsanford/twitter-text-rb

However, it seems I need to install unicode support.  On Linux, I was
able to, though on Windows 7, I don't have nmake (don't have C++).
Anyways, it still complains about setting $KCODE to utf8 or u (or
using the -KU command line switch).  I tried both but can't seem to
make it work.  Which gem do I need for unicode, and how can I set it
programmatically?

I tried ideas like this:

require 'rubygems'
require 'unicode'
$KCODE = 'KU'


-- 
To unsubscribe, reply using "remove me" as the subject.

Re: [twitter-dev] Re: Bulk User Relationship Lookup?

[Raffi Krikorian]

really?  that's interesting.  i have tests for it working in oauth  can
you send me details, please?

On Sun, Apr 11, 2010 at 12:38 AM, Orian Marx (@orian)
wrote:

> Also, does this endpoint support oauth? I seem to be having trouble
> making an oauth request to it vs basic-auth.
>
> On Apr 9, 12:17 pm, Raffi Krikorian  wrote:
> > at the risk of introducing features instead of fixing bugs, this endpoint
> > may also be of use -- its a work in progress, and a few details of it may
> > change:
> >
> > http://api.twitter.com/1/friendships/lookup.xml?user_id=813286,783214
> >
> > On Wed, Mar 31, 2010 at 8:02 AM, Orian Marx (@orian) <
> or...@orianmarx.com>wrote:
> >
> >
> >
> >
> >
> > > I would certainly be interested in such a list, but no I don't think
> > > Twitter will be providing one.
> >
> > > On Mar 30, 9:26 pm, mcfnord  wrote:
> > > > Hi, Abraham, and everyone.
> >
> > > > I'm crawling twitter. (But who isn't, right?) Us social graph geeks
> > > > have our own advantages, and our own set of challenges.
> > > > For example, I would not want to manage the vastness of tweet
> volumes.
> > > > But I do get neck-deep in social graph data. Which means I crawl with
> > > > this:http://twitter.com/friends/ids.xml/?user_id=12345
> > > > x20,000/hr.
> > > > so far i've discovered existance of 51 million accounts, and examined
> > > > 13 million of these. if i need two scrapes to determine account
> > > > activity, then i've got just 89 million captures to go! that's 6
> > > > months at full speed.
> >
> > > > inactive accounts can live with a vastly slower refresh cycle.
> > > > so really what would benefit me (and twitter, as i see it) is a cheat
> > > > sheet of active vs. inactive accounts.
> > > > download the file, and know the integers within it are active
> > > > accounts.
> >
> > > > in one move, through occasional publication of one file, twitter
> saves
> > > > 6 months of scrapes for anyone who can leverage a quick-start list of
> > > > which accounts are active, and which are inactive. i imagine people
> > > > could, in many scenarios, limit their entire set of inquiries to
> these
> > > > active accounts, saving millions of calls to twitter's api.
> >
> > > > maybe it's bad p.r. to state explicitly which accounts merit
> resources
> > > > and which are dead.
> >
> > > > i guess once it's over i won't look back and perhaps it is i who can
> > > > publish this dataset to some other newbie. but what a great
> efficiency
> > > > for twitter to avoid this for everyone in my shoes. which are small
> > > > shoes, i accept.
> >
> > > > best regards,
> > > > john
> >
> > > > On Mar 23, 11:56 am, Abraham Williams <4bra...@gmail.com> wrote:
> >
> > > > > Bulk lookup of social graphs seems like it would be a pretty
> resource
> > > > > intensive call. I would not hold my breath for Twitter to implement
> it.
> >
> > > > > Abraham
> >
> > > > > On Tue, Mar 23, 2010 at 08:21,OrianMarx (@orian) <
> or...@orianmarx.com
> > > >wrote:
> >
> > > > > > Thanks Abraham, don't worry I'm watching Intersect closely ;)
> >
> > > > > > Unfortunately, this doesn't currently address what I'm getting
> at,
> > > > > > namely, if I use the bulk user lookup, I'd like to similarly get
> > > > > > accurate friend / follower info for each of those users (relative
> to
> > > > > > the user making the bulk lookup) in one call.
> >
> > > > > > On Mar 22, 11:00 pm, Abraham Williams <4bra...@gmail.com> wrote:
> > > > > > > I provide a simple API that returns common friends and follower
> of
> > > two
> > > > > > > specific Twitter users. It currently works for the 5000 most
> recent
> > > > > > > (although soon to be increasing) and only on public accounts.
> >
> > > > > > >http://github.com/abraham/intersect/blob/master/README
> >
> > > > > > >  >Abraham
> >
> > > > > > > On Mon, Mar 22, 2010 at 19:41,OrianMarx (@orian) <
> > > or...@orianmarx.com
> > > > > > >wrote:
> >
> > > > > > > > The bulk users/lookup call recently added to the API is a
> great
> > > new
> > > > > > > > tool for developers. This call would become even more useful
> with
> > > a
> > > > > > > > corresponding bulk lookup for user relationships. Are there
> any
> > > plans
> > > > > > > > for this?
> >
> > > > > > > > Also, I'm assuming that the  and 
> nodes
> > > > > > > > returned in the user objects of the users/lookup call should
> be
> > > > > > > > considered unreliable as is stated for users/show.
> >
> > > > > > > > Thanks,
> > > > > > > > @orian
> >
> > > > > > > > To unsubscribe from this group, send email to
> > > twitter-development-talk+
> > > > > > > > unsubscribegooglegroups.com or reply to this email with the
> > > words
> > > > > > "REMOVE
> > > > > > > > ME" as the subject.
> >
> > > > > > > --
> > > > > > > Abraham Williams | Community Advocate |http://abrah.am
> > > > > > > TwitterOAuth |http://github.com/abraham/twitteroauth
> > > > > > > This email is: [ ] shareable [x] ask first [ 

Re: [twitter-dev] Re: Bulk User Relationship Lookup?

[Raffi Krikorian]

no - not yet.  like i said, this endpoint is definitely a work in progress.

On Sat, Apr 10, 2010 at 10:27 PM, Orian Marx (@orian)
wrote:

> Any way I can specify a target other than myself for who to lookup
> relationships against?
>
> On Apr 9, 12:17 pm, Raffi Krikorian  wrote:
> > at the risk of introducing features instead of fixing bugs, this endpoint
> > may also be of use -- its a work in progress, and a few details of it may
> > change:
> >
> > http://api.twitter.com/1/friendships/lookup.xml?user_id=813286,783214
> >
> > On Wed, Mar 31, 2010 at 8:02 AM, Orian Marx (@orian) <
> or...@orianmarx.com>wrote:
> >
> >
> >
> >
> >
> > > I would certainly be interested in such a list, but no I don't think
> > > Twitter will be providing one.
> >
> > > On Mar 30, 9:26 pm, mcfnord  wrote:
> > > > Hi, Abraham, and everyone.
> >
> > > > I'm crawling twitter. (But who isn't, right?) Us social graph geeks
> > > > have our own advantages, and our own set of challenges.
> > > > For example, I would not want to manage the vastness of tweet
> volumes.
> > > > But I do get neck-deep in social graph data. Which means I crawl with
> > > > this:http://twitter.com/friends/ids.xml/?user_id=12345
> > > > x20,000/hr.
> > > > so far i've discovered existance of 51 million accounts, and examined
> > > > 13 million of these. if i need two scrapes to determine account
> > > > activity, then i've got just 89 million captures to go! that's 6
> > > > months at full speed.
> >
> > > > inactive accounts can live with a vastly slower refresh cycle.
> > > > so really what would benefit me (and twitter, as i see it) is a cheat
> > > > sheet of active vs. inactive accounts.
> > > > download the file, and know the integers within it are active
> > > > accounts.
> >
> > > > in one move, through occasional publication of one file, twitter
> saves
> > > > 6 months of scrapes for anyone who can leverage a quick-start list of
> > > > which accounts are active, and which are inactive. i imagine people
> > > > could, in many scenarios, limit their entire set of inquiries to
> these
> > > > active accounts, saving millions of calls to twitter's api.
> >
> > > > maybe it's bad p.r. to state explicitly which accounts merit
> resources
> > > > and which are dead.
> >
> > > > i guess once it's over i won't look back and perhaps it is i who can
> > > > publish this dataset to some other newbie. but what a great
> efficiency
> > > > for twitter to avoid this for everyone in my shoes. which are small
> > > > shoes, i accept.
> >
> > > > best regards,
> > > > john
> >
> > > > On Mar 23, 11:56 am, Abraham Williams <4bra...@gmail.com> wrote:
> >
> > > > > Bulk lookup of social graphs seems like it would be a pretty
> resource
> > > > > intensive call. I would not hold my breath for Twitter to implement
> it.
> >
> > > > > Abraham
> >
> > > > > On Tue, Mar 23, 2010 at 08:21,OrianMarx (@orian) <
> or...@orianmarx.com
> > > >wrote:
> >
> > > > > > Thanks Abraham, don't worry I'm watching Intersect closely ;)
> >
> > > > > > Unfortunately, this doesn't currently address what I'm getting
> at,
> > > > > > namely, if I use the bulk user lookup, I'd like to similarly get
> > > > > > accurate friend / follower info for each of those users (relative
> to
> > > > > > the user making the bulk lookup) in one call.
> >
> > > > > > On Mar 22, 11:00 pm, Abraham Williams <4bra...@gmail.com> wrote:
> > > > > > > I provide a simple API that returns common friends and follower
> of
> > > two
> > > > > > > specific Twitter users. It currently works for the 5000 most
> recent
> > > > > > > (although soon to be increasing) and only on public accounts.
> >
> > > > > > >http://github.com/abraham/intersect/blob/master/README
> >
> > > > > > >  >Abraham
> >
> > > > > > > On Mon, Mar 22, 2010 at 19:41,OrianMarx (@orian) <
> > > or...@orianmarx.com
> > > > > > >wrote:
> >
> > > > > > > > The bulk users/lookup call recently added to the API is a
> great
> > > new
> > > > > > > > tool for developers. This call would become even more useful
> with
> > > a
> > > > > > > > corresponding bulk lookup for user relationships. Are there
> any
> > > plans
> > > > > > > > for this?
> >
> > > > > > > > Also, I'm assuming that the  and 
> nodes
> > > > > > > > returned in the user objects of the users/lookup call should
> be
> > > > > > > > considered unreliable as is stated for users/show.
> >
> > > > > > > > Thanks,
> > > > > > > > @orian
> >
> > > > > > > > To unsubscribe from this group, send email to
> > > twitter-development-talk+
> > > > > > > > unsubscribegooglegroups.com or reply to this email with the
> > > words
> > > > > > "REMOVE
> > > > > > > > ME" as the subject.
> >
> > > > > > > --
> > > > > > > Abraham Williams | Community Advocate |http://abrah.am
> > > > > > > TwitterOAuth |http://github.com/abraham/twitteroauth
> > > > > > > This email is: [ ] shareable [x] ask first [ ] private.
> >
> > > > > > To unsubscribe from this 

Re: [twitter-dev] Can an authorize URL pass through a parameter?

[Raffi Krikorian]

>
> The specific one first. When I registered my application with Twitter, it
> made me specify a callback URL. In fact, what page I want Twitter to "call
> back" depends on what the user is doing! Consequently, the callback page
> must figure out what the user was doing and redirect to one of several other
> pages, as appropriate.
>
> That will be a lot easier if I can furnish the authorize URL with a
> parameter that Twitter will return to the callback URL along with the token
> that it provides. Is that possible?
>

i don't think this is possible in oauth 1.0a.  i know oauth 2.0 has a state
parameter (don't quote me on the name) that will allow clients to pass an
opaque string to the server who will then pass it back.

-- 
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

Re: [twitter-dev] Twitter REST API Method: POST /:user/:list_id/members ???

[Tim Haines]

Raffi - I'd love it if I could look up 500 list member's ids at a time.
 Don't need the full user object, just the ids.  User objects would be a
bonus.

Tim.

On Sun, Apr 11, 2010 at 3:09 PM, Raffi Krikorian  wrote:

> not yet, right now.  but that's a good idea -- we've been on a kick of
> "bulk-ifying" our methods, and i'll add that to our list.
>
>
> On Sat, Apr 10, 2010 at 2:24 PM, adamjamesdrew wrote:
>
>> Twitter REST API Method: POST /:user/:list_id/members
>>
>> http://api.twitter.com/1/user/list_id/members.format
>>
>> Can you add more than one user at a time?
>>
>>
>> --
>> To unsubscribe, reply using "remove me" as the subject.
>>
>
>
>
> --
> Raffi Krikorian
> Twitter Platform Team
> http://twitter.com/raffi
>

[twitter-dev] Re: Bulk User Relationship Lookup?

[Orian Marx (@orian)]

Also, does this endpoint support oauth? I seem to be having trouble
making an oauth request to it vs basic-auth.

On Apr 9, 12:17 pm, Raffi Krikorian  wrote:
> at the risk of introducing features instead of fixing bugs, this endpoint
> may also be of use -- its a work in progress, and a few details of it may
> change:
>
> http://api.twitter.com/1/friendships/lookup.xml?user_id=813286,783214
>
> On Wed, Mar 31, 2010 at 8:02 AM, Orian Marx (@orian) 
> wrote:
>
>
>
>
>
> > I would certainly be interested in such a list, but no I don't think
> > Twitter will be providing one.
>
> > On Mar 30, 9:26 pm, mcfnord  wrote:
> > > Hi, Abraham, and everyone.
>
> > > I'm crawling twitter. (But who isn't, right?) Us social graph geeks
> > > have our own advantages, and our own set of challenges.
> > > For example, I would not want to manage the vastness of tweet volumes.
> > > But I do get neck-deep in social graph data. Which means I crawl with
> > > this:http://twitter.com/friends/ids.xml/?user_id=12345
> > > x20,000/hr.
> > > so far i've discovered existance of 51 million accounts, and examined
> > > 13 million of these. if i need two scrapes to determine account
> > > activity, then i've got just 89 million captures to go! that's 6
> > > months at full speed.
>
> > > inactive accounts can live with a vastly slower refresh cycle.
> > > so really what would benefit me (and twitter, as i see it) is a cheat
> > > sheet of active vs. inactive accounts.
> > > download the file, and know the integers within it are active
> > > accounts.
>
> > > in one move, through occasional publication of one file, twitter saves
> > > 6 months of scrapes for anyone who can leverage a quick-start list of
> > > which accounts are active, and which are inactive. i imagine people
> > > could, in many scenarios, limit their entire set of inquiries to these
> > > active accounts, saving millions of calls to twitter's api.
>
> > > maybe it's bad p.r. to state explicitly which accounts merit resources
> > > and which are dead.
>
> > > i guess once it's over i won't look back and perhaps it is i who can
> > > publish this dataset to some other newbie. but what a great efficiency
> > > for twitter to avoid this for everyone in my shoes. which are small
> > > shoes, i accept.
>
> > > best regards,
> > > john
>
> > > On Mar 23, 11:56 am, Abraham Williams <4bra...@gmail.com> wrote:
>
> > > > Bulk lookup of social graphs seems like it would be a pretty resource
> > > > intensive call. I would not hold my breath for Twitter to implement it.
>
> > > > Abraham
>
> > > > On Tue, Mar 23, 2010 at 08:21,OrianMarx (@orian)  > >wrote:
>
> > > > > Thanks Abraham, don't worry I'm watching Intersect closely ;)
>
> > > > > Unfortunately, this doesn't currently address what I'm getting at,
> > > > > namely, if I use the bulk user lookup, I'd like to similarly get
> > > > > accurate friend / follower info for each of those users (relative to
> > > > > the user making the bulk lookup) in one call.
>
> > > > > On Mar 22, 11:00 pm, Abraham Williams <4bra...@gmail.com> wrote:
> > > > > > I provide a simple API that returns common friends and follower of
> > two
> > > > > > specific Twitter users. It currently works for the 5000 most recent
> > > > > > (although soon to be increasing) and only on public accounts.
>
> > > > > >http://github.com/abraham/intersect/blob/master/README
>
> > > > > > Abraham
>
> > > > > > On Mon, Mar 22, 2010 at 19:41,OrianMarx (@orian) <
> > or...@orianmarx.com
> > > > > >wrote:
>
> > > > > > > The bulk users/lookup call recently added to the API is a great
> > new
> > > > > > > tool for developers. This call would become even more useful with
> > a
> > > > > > > corresponding bulk lookup for user relationships. Are there any
> > plans
> > > > > > > for this?
>
> > > > > > > Also, I'm assuming that the  and  nodes
> > > > > > > returned in the user objects of the users/lookup call should be
> > > > > > > considered unreliable as is stated for users/show.
>
> > > > > > > Thanks,
> > > > > > > @orian
>
> > > > > > > To unsubscribe from this group, send email to
> > twitter-development-talk+
> > > > > > > unsubscribegooglegroups.com or reply to this email with the
> > words
> > > > > "REMOVE
> > > > > > > ME" as the subject.
>
> > > > > > --
> > > > > > Abraham Williams | Community Advocate |http://abrah.am
> > > > > > TwitterOAuth |http://github.com/abraham/twitteroauth
> > > > > > This email is: [ ] shareable [x] ask first [ ] private.
>
> > > > > To unsubscribe from this group, send email to
> > twitter-development-talk+
> > > > > unsubscribegooglegroups.com or reply to this email with the words
> > "REMOVE
> > > > > ME" as the subject.
>
> > > > --
> > > > Abraham Williams | Community Advocate |http://abrah.am
> > > > TwitterOAuth |http://github.com/abraham/twitteroauth
> > > > This email is: [ ] shareable [x] ask first [ ] private.- Hide quoted
> > text -
>
> > > > - Show quoted text -
>