Our intention is that User Streams and Site Streams will, shortly, offer the
same data and filtering options at a similar, if not identical, QoS. I'm
sure some subtleties will creep in over time, as they always do, but this
parity is our goal.

The major difference is that User Streams, given its higher per-user cost,
is limited only to user-based applications that connect directly to the
Twitter API. In this use case, we have no alternative but to service a
connection from each user device. Site Streams, on the other hand, allows
services, such as your website, to open many User Streams multiplexed over a
smaller number of connections. This reduces per-user cost, and makes large
scale integrations tractable. Several pretty large services have integrated
with Site Streams in just a few days, so this multiplexing is unlikely to be
an undue additional burden over a User Streams integration, and might even
save a lot of work over time.

If you attempt to use User Streams from a service, we can trivially detect
this situation, and we'll classify your usage as against the TOS. To put our
current thinking as bluntly as possible: we intend to enforce the
distinction between User Streams and Site Streams via revocation of access.

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



On Wed, Sep 15, 2010 at 12:24 PM, Justin <justin.carl...@gmail.com> wrote:

> I've successfully migrated one of my sites away from making search and
> mention rest calls, switched over to the streaming API and I'm loving
> it. I still need to move it to OAuth but now that I have that in test
> I'm reading up on the User and Site streams and I have a question.
>
> It seems the User stream states that websites should not use it, and
> should use the Site stream instead, but I don't consume or care about
> my user's activity, my site is centered around the messages and
> interactions with the application user not the users themselves.
>
> Right now I track and evaluate followers and other bits using the rest
> calls but from what I see I could eliminate those rest calls and be
> off them (possibly) all together if I could use the User stream to
> accept information about new and broken friendships, favorites, dms,
> etc.
>
> Is it acceptable to use the User stream in that manor since I would
> only need it for the app user account not my site user's accounts? If
> so, I can just maintain the two streams (filtered streaming api and
> user stream) and eliminate or cut back my rest calls dramatically?
> Please let me know so I can plan accordingly.
>
> --
> Twitter developer documentation and resources: http://dev.twitter.com/doc
> API updates via Twitter: http://twitter.com/twitterapi
> Issues/Enhancements Tracker:
> http://code.google.com/p/twitter-api/issues/list
> Change your membership to this group:
> http://groups.google.com/group/twitter-development-talk?hl=en
>

-- 
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: 
http://groups.google.com/group/twitter-development-talk?hl=en

Reply via email to