User Stream's API usage

[Jud]

I'm in the chrip conference IP address range, but
http://chirpstream.twitter.com/2b/user.json usage isn't clear.

- the follow predicate in a POST doesn't work (should it?)
- track as a predicate gets accepted, but no data comes through (I get
a single '{"friends":[]}', but that's it)
- am I supposed to be tracking userids or names or keywords?

is the resource simply not turned on until later at/on the hackathon's
network?

[John Kalucki]

Email me your account name. You are in, but not getting data. Also, is
this account following anyone?

Typos by iPhone.

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

[Jud]

On Apr 14, 7:17 pm, John Kalucki <j...@twitter.com> wrote:
> Email me your account name.

done

> You are in, but not getting data. Also, is this account following anyone?

it is not

[John Kalucki]

If you aren't following anyone, and aren't tracking any terms, there's nothing to see, other than actions that occur on your account. So, if another account favorites this account's tweets, you'll see that, for example, or if another account follows your account, etc.

Add some followings and reconnect to get something more interesting.

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

[Kovas Boguts]

Hi,

Is there any description of how to use this? I don't understand how to
use track with this or what is generally available for hack day. Thanks!

[Mark McBride]

Some sample APIs...

curl -u<youruser>:<yourpass> http://chirpstream.twitter.com/2b/user.json

Will give you a stream of your home timeline, social activity from your friends, and direct messages.

curl -u<youruser>:<yourpass> "http://chirpstream.twitter.com/2b/user.json?track=#chirp"

Will give you all of the above, plus any tweets matching #chirp

Does that clear it up?  If not, I'm currently near "The Coop".

  ---Mark

http://twitter.com/mccv

[John Kalucki]

I should have encouraged folks to understand the Streaming API first. You can read up on all the details here:
http://apiwiki.twitter.com/Streaming-API-Documentation

But, for a prototype, just dive right in.

-John

[Isaiah Carew]

Any chance on getting access to a beta of these from outside chirp?  I had to come home this afternoon and didn't get to play too much while i was there, but would be really interested in playing more.  I understand it's not ready for roll out.  Just looking to start the development process.

isaiah

http://twitter.com/isaiah

[John Kalucki]

Once the conference is over, we'll open the preview up to developers everywhere. A few more hours to go...

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

[Dewald Pretorius]

John,

I know it is still some ways off into the future, but would you
consider segmenting out the areas of user streams that don't have
privacy implications, to make those parts of the stream available to
services as a higher priority compared with the rest?

For me, social graph changes are the biggest pain point in terms of
processing and delays (and in some cases impracticality) in providing
services to users.

I can imagine that there will be scalability issues, because a service
will have to be able to subscribe to the streams of hundreds of
thousands or more users.

Nonetheless, consideration will be much appreciated.

On Apr 15, 8:32 pm, John Kalucki <j...@twitter.com> wrote:
> Once the conference is over, we'll open the preview up to developers
> everywhere. A few more hours to go...
>

> -John Kaluckihttp://twitter.com/jkalucki

> Infrastructure, Twitter Inc.
>
>
>
> On Thu, Apr 15, 2010 at 3:49 PM, Isaiah Carew <isa...@me.com> wrote:
>
> > Any chance on getting access to a beta of these from outside chirp?  I had
> > to come home this afternoon and didn't get to play too much while i was
> > there, but would be really interested in playing more.  I understand it's
> > not ready for roll out.  Just looking to start the development process.
>
> > isaiah
> >http://twitter.com/isaiah
>
> > On Apr 14, 2010, at 9:26 PM, John Kalucki wrote:
>
> > I should have encouraged folks to understand the Streaming API first. You
> > can read up on all the details here:
> >http://apiwiki.twitter.com/Streaming-API-Documentation
>
> > But, for a prototype, just dive right in.
>
> > -John
>

> > On Wed, Apr 14, 2010 at 9:15 PM, Mark McBride <mmcbr...@twitter.com>wrote:
>
> >> Some sample APIs...
>

> >> curl -u<youruser>:<yourpass>http://chirpstream.twitter.com/2b/user.jso<http://chirpstream.twitter.com/2b/user.json>
> >> n

>
> >> Will give you a stream of your home timeline, social activity from your
> >> friends, and direct messages.
>

> >> curl -u<youruser>:<yourpass> "http://chirpstream.twitter.com/2b/user.jso<http://chirpstream.twitter.com/2b/user.json>

> >> n?track=#chirp"
>
> >> Will give you all of the above, plus any tweets matching #chirp
>
> >> Does that clear it up?  If not, I'm currently near "The Coop".
>
> >>   ---Mark
>
> >>http://twitter.com/mccv
>

> >> On Wed, Apr 14, 2010 at 6:37 PM, Kovas Boguts <kovas.bog...@gmail.com>wrote:
>
> >>> Hi,
>
> >>> Is there any description of how to use this? I don't understand how to
> >>> use track with this or what is generally available for hack day. Thanks!
>

> >>> On Apr 14, 2010, at 4:17 PM, John Kalucki <j...@twitter.com> wrote:
>
> >>>  Email me your account name. You are in, but not getting data. Also, is
> >>>> this account following anyone?
>
> >>>> Typos by iPhone.
>

> >>>> On Apr 14, 2010, at 4:11 PM, Jud <jvale...@gmail.com> wrote:
>
> >>>>  I'm in the chrip conference IP address range, but

> >>>>>http://chirpstream.twitter.com/2b/user.jsonusage isn't clear.

>
> >>>>> - the follow predicate in a POST doesn't work (should it?)
> >>>>> - track as a predicate gets accepted, but no data comes through (I get
> >>>>> a single '{"friends":[]}', but that's it)
> >>>>> - am I supposed to be tracking userids or names or keywords?
>
> >>>>> is the resource simply not turned on until later at/on the hackathon's
> >>>>> network?
>
> >>>>> --

> >>>>> To unsubscribe, reply using "remove me" as the subject.- Hide quoted text -
>
> - Show quoted text -

[Jonathon Hill]

I would like to request the addition of another piece of information
to the user stream: user profile changes. Anytime the user changes any
part of their profile data, it would be helpful to stream that change.

Also will there be any way to consume user streams for multiple users?

Thanks,

Jonathon Hill
Company52
http://company52.com
@compwright

On Apr 15, 7:46 pm, Dewald Pretorius <dpr...@gmail.com> wrote:
> John,
>
> I know it is still some ways off into the future, but would you

> consider segmenting out the areas ofuserstreams that don't have

> privacy implications, to make those parts of the stream available to
> services as a higher priority compared with the rest?
>
> For me, social graph changes are the biggest pain point in terms of
> processing and delays (and in some cases impracticality) in providing
> services to users.
>
> I can imagine that there will be scalability issues, because a service
> will have to be able to subscribe to the streams of hundreds of
> thousands or more users.
>
> Nonetheless, consideration will be much appreciated.
>
> On Apr 15, 8:32 pm, John Kalucki <j...@twitter.com> wrote:
>
>
>
> > Once the conference is over, we'll open the preview up to developers
> > everywhere. A few more hours to go...
>
> > -John Kaluckihttp://twitter.com/jkalucki
> > Infrastructure, Twitter Inc.
>
> > On Thu, Apr 15, 2010 at 3:49 PM, Isaiah Carew <isa...@me.com> wrote:
>
> > > Any chance on getting access to a beta of these from outside chirp?  I had
> > > to come home this afternoon and didn't get to play too much while i was
> > > there, but would be really interested in playing more.  I understand it's
> > > not ready for roll out.  Just looking to start the development process.
>
> > > isaiah
> > >http://twitter.com/isaiah
>
> > > On Apr 14, 2010, at 9:26 PM, John Kalucki wrote:
>

> > > I should have encouraged folks to understand theStreamingAPI first. You

> > >>>>>http://chirpstream.twitter.com/2b/user.jsonusageisn't clear.

[kovas boguta]

I second this.

Also, unfollows should be treated the same as follows. I know its sad
when an unfollow happens, but this is important information too.

Basically I would expect the data in the user stream to mirror what is
available by repeatedly scraping the REST API for updates. I guess one
missing piece there would be changes to Lists being sent in the stream
as well.

That said I think what is currently in the user stream is the most
important essential info, so good job there.

[Cameron Kaiser]

> Also, unfollows should be treated the same as follows. I know its sad
> when an unfollow happens, but this is important information too.

I disagree. I think unfollows should be totally without penalty, and making
them visible/exposed could depending on the situation assign them a very
heavy social penalty. Qwitter comes to mind.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- "EH! STEVE!" ---------------------------------------------------------------


--
Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en

[Mark McBride]

We likely won't send down the unfollows in the short term, for reasons
outlined previously. It's not that we won't *ever* do it, but it's
delicate.

On the user profile changes, that does seem like a good idea. No
promises, but I'll look at what we can do. The highest priorities we
have right now are

1) Getting the formatting of messages locked down
2) Getting list activity in (lists created/deleted/modified, users
added to lists, etc.)

---Mark

http://twitter.com/mccv

[Jonathon Hill]

What's wrong with Qwitter? I don't get it.

Jonathon Hill

On Apr 21, 4:30 pm, Cameron Kaiser <spec...@floodgap.com> wrote:
> > Also, unfollows should be treated the same as follows. I know its sad
> > when an unfollow happens, but this is important information too.
>
> I disagree. I think unfollows should be totally without penalty, and making
> them visible/exposed could depending on the situation assign them a very
> heavy social penalty. Qwitter comes to mind.
>
> --
> ------------------------------------ personal:http://www.cameronkaiser.com/--

>   Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com

[Cameron Kaiser]

> > > Also, unfollows should be treated the same as follows. I know its sad
> > > when an unfollow happens, but this is important information too.
> >
> > I disagree. I think unfollows should be totally without penalty, and making
> > them visible/exposed could depending on the situation assign them a very
> > heavy social penalty. Qwitter comes to mind.
>

> What's wrong with Qwitter? I don't get it.

YOU BASTARD HOW DARE YOU UNFOLLOW ME YOU REALLY THINK THAT OF ME YOU CAN GO F
etc.

Some people take it personally. Qwitter makes it easy to know who left, and
for those kinds of people, they don't respond well to it.

I think it's a depth best left unplumbed.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- They told me I was gullible ... and I believed them. -----------------------

[Abraham Williams]

I actually had one time where someone interesting that I wanted to follow unfollowed me and when I noticed because of @unfollowr I started following them and they followed me back. :)

--
Abraham Williams | Developer for hire | http://abrah.am
@abraham | http://projects.abrah.am | http://blog.abrah.am
This email is: [ ] shareable [x] ask first [ ] private.

[Orian Marx (@orian)]

Being able to retrieve a list of unfollows a user performed since some
point in time would be hugely valuable for anyone trying to maintain
an up-to-date record of a user's connections without regularly having
to refetch all the ids. Is there any way this could be accomplished,
perhaps as a REST endpoint?

On Apr 21, 5:00 pm, Mark McBride <mmcbr...@twitter.com> wrote:
> We likely won't send down the unfollows in the short term, for reasons
> outlined previously.  It's not that we won't *ever* do it, but it's
> delicate.
>
> On the user profile changes, that does seem like a good idea.  No
> promises, but I'll look at what we can do.  The highest priorities we
> have right now are
>
> 1) Getting the formatting of messages locked down
> 2) Getting list activity in (lists created/deleted/modified, users
> added to lists, etc.)
>
>    ---Mark
>
> http://twitter.com/mccv
>
>
>
> On Wed, Apr 21, 2010 at 1:30 PM, Cameron Kaiser <spec...@floodgap.com> wrote:
> >> Also, unfollows should be treated the same as follows. I know its sad
> >> when an unfollow happens, but this is important information too.
>
> > I disagree. I think unfollows should be totally without penalty, and making
> > them visible/exposed could depending on the situation assign them a very
> > heavy social penalty. Qwitter comes to mind.
>
> > --
> > ------------------------------------ personal:http://www.cameronkaiser.com/--

> >  Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com

[John Kalucki]

The utility of various use cases has to be balanced with the overall
Twitter experience that affects every Twitter user. I'd guess that the
product team is generally going to bias away from exposing unfollows
to the population at large, while not restricting unfollow discovery
from motivated parties. Also, the product team will, just as in any
company, always bias towards building features that affect the
population at large. So, these features fall into the null
intersection of these two disjoint sets. Given competing priorities,
little is likely to be done here unless there was a huge efficiency
gain to be had somewhere...

-John Kalucki

http://twitter.com/jkalucki
Infrastructure, Twitter Inc.