Blocked users appear in the API, not in the website

3 views
Skip to first unread message

Julio Biason

unread,
Sep 8, 2010, 12:45:27 PM9/8/10
to twitter-deve...@googlegroups.com
Guys,

I opened this bug about a year ago but it got lost in the bug tracking
and I'm not in the mood to search that mess again.

http://imgur.com/JTxm1.png

As you can see, there is one tweet that appears in the application,
but it doesn't appear in the website. The reason is that the author of
the tweet (the original tweet, not the retweet) is blocked, which the
website does it right and don't display it, but the message still
appears in the API.

And no, I'm not the author or am in anyway related to Nambu, but I had
the same problem with my (now defunct) application.

--
Julio Biason <julio....@gmail.com>
Twitter: http://twitter.com/juliobiason

Tom van der Woerdt

unread,
Sep 8, 2010, 12:54:32 PM9/8/10
to twitter-deve...@googlegroups.com
The API doesn't check for blocked users. You need to implement that
manually.

Tom

Julio Biason

unread,
Sep 8, 2010, 1:15:52 PM9/8/10
to twitter-deve...@googlegroups.com
On Wed, Sep 8, 2010 at 1:54 PM, Tom van der Woerdt <in...@tvdw.eu> wrote:
> The API doesn't check for blocked users. You need to implement that
> manually.

So for every request for the user_timeline I need to request the list
of blocked users, to have a proper list in case the user blocks
someone in the website?

That sounds incredible stupid.

Tom van der Woerdt

unread,
Sep 8, 2010, 1:17:49 PM9/8/10
to twitter-deve...@googlegroups.com
On 9/8/10 7:15 PM, Julio Biason wrote:
> On Wed, Sep 8, 2010 at 1:54 PM, Tom van der Woerdt <in...@tvdw.eu> wrote:
>> The API doesn't check for blocked users. You need to implement that
>> manually.
>
> So for every request for the user_timeline I need to request the list
> of blocked users, to have a proper list in case the user blocks
> someone in the website?
>
> That sounds incredible stupid.
>

I'm not 100% about my last post. Anyway, the documentation says this
about blocks :
> The block list should be cached locally - the change velocity is usually quite low. If possible, save the cache to disk to avoid polling for the block list upon startup. Timestamp the block list write time and only update perhaps as infrequently as every 6 to 24 hours.

Tom

Reply all
Reply to author
Forward
0 new messages