Streaming API -- /follow /birddog and /shadow also match in_reply_to field.

[John Kalucki]

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

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

-John Kalucki
Services, Twitter Inc.

[Chad Etzel]

Neato!

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

Would be handy, perhaps.
-Chad

[John Kalucki]

Unlikely.

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

-John

On Jun 9, 8:10 pm, Chad Etzel <jazzyc...@gmail.com> wrote:
> Neato!
>
> Would it be possible to add some sort of attribute to the status
> object which indicates when this is the case? (i.e. this update is
> being sent to you, but the user id of the sender is not explicitly in
> the follow id list?)
>
> Would be handy, perhaps.
> -Chad
>

[Chad Etzel]

Makes sense.

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

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

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

-Chad

[John Kalucki]

This is a known defect. Quick catch! The fix is easy enough and
required for future features.

Streaming API clients need to de-duplicate for a whole host of other
reasons, especially those who use the count parameter. The service
errs on the side of overdelivery.

-John
Service, Twitter Inc.

On Jun 9, 9:00 pm, Chad Etzel <jazzyc...@gmail.com> wrote:
> Makes sense.
>
> One thing I'm noticing that now this feature is live:
>
> If userA and userB are both in my follow id list, and then if userA
> makes an explicit reply to userB, I get userA's update twice.  Just
> something to be aware of for everyone.
>
> This "duplicate update" also happens if you have the same user id
> listed twice (or more) in the follow id list.  I found this out by
> merging two follow lists which overlapped.  'sort' and 'uniq' became
> my friends soon thereafter.
>
> -Chad
>

[Chad Etzel]

Cool, thanks.

I have noticed that the duplicates have always (thus far) come in
back-to-back, so I've just started checking the tweet id against the
last received tweet id to see if they match. Do you know if that
should always be the case (until the fix), or if I have just been
getting lucky so far?

-Chad

[John Kalucki]

For this issue, and all filtering-driven issues, they'll always be
back-to-back. For other causes of overdelivery, duplicates can be
scattered pretty far apart. Overdelivery is usually triggered by
lifecycle events -- servers restarting, your client reconnecting, that
sort of thing. This type of overdelivery is rare, but it can happen.

-John

On Jun 10, 10:09 am, Chad Etzel <jazzyc...@gmail.com> wrote:
> Cool, thanks.
>
> I have noticed that the duplicates have always (thus far) come in
> back-to-back, so I've just started checking the tweet id against the
> last received tweet id to see if they match.  Do you know if that
> should always be the case (until the fix), or if I have just been
> getting lucky so far?
>
> -Chad
>