屋久島沈没

User Stream 時代の Twitter の過し方

ブログ書こうと思ってエディタ開いたら、このブログの中身の ChangeLog Memo が度重なるマージによって変なことになってた、執筆の前にとんだゴミ処理させられたぜこんちくしょうが。
このブログ、歴史的な経緯で、 dotfile や Plagger の yaml やらが入った git リポジトリに同居していて、いろいろ面倒なので分離させたい。あとでやる(永遠にやらない)

そんな訳で本題。 Hello 糞野郎ども。 Twitter の話。 Basic 認証や OAuth で RESTful な API を叩いては生活されているかと思います。最近、そこに Streaming API が追加されました。従来あった Streaming API (firehose gardenhose sample track) とは違ってユーザー向の Streaming です。

これはどういうものかというと、かつての IM のように、 following の行動がリアルタイムで push されてくるというものです。よかったですね。

かつての IM とは違うところはプロトコルが Jabber ではなく HTTP で、 following の RT Fav Follow Delete が流れてくる、というところでしょうか。

実のところ、 Streaming であるというのは大した話ではなくて、従来の API を使うより、数十秒早くタイムラインを取得出来るという程度のことです。問題は RT Fav Follow Delete が流れてくるということです。以下使い方と共に実例を示します。

現在 User Streaming は

http://chirpstream.twitter.com/2b/user.json

に Basic 認証をかけて GET すれば使うことが出来ます。 JSON がガンガン流れてくるので、一行ごとに区切って処理していきましょう。ちなみに、ベータ版(&仕様に問題アリ)ですので、多分そのうちサクっと使えなくなります。

流れてくるもの。

1.tweet

{"coordinates"=>nil, "truncated"=>false, "created_at"=>"Sun Apr 25 14:09:59 +0000 2010", "favorited"=>false, "text"=>"@peachchch @siguri にならおこられｔｍ （ｒｙ", "contributors"=>nil, "id"=>12823261895, "geo"=>nil, "in_reply_to_user_id"=>24514923, "in_reply_to_screen_name"=>"peachchch", "source"=>"<a href=\"http://www.misuzilla.org/dist/net/twitterircgateway/\" rel=\"nofollow\">TwitterIrcGateway</a>", "place"=>nil, "user"=>{"profile_sidebar_fill_color"=>"c28c8c", "profile_sidebar_border_color"=>"405add", "name"=>"紫雪", "profile_background_tile"=>false, "created_at"=>"Mon May 07 09:06:35 +0000 2007", "location"=>"Nagoya Japan", "profile_image_url"=>"http://a3.twimg.com/profile_images/781317847/icon2_by_chrcc_normal.png", "profile_link_color"=>"e8b7b1", "favourites_count"=>682, "contributors_enabled"=>false, "url"=>"http://iddy.jp/profile/shisetu/", "id"=>5827682, "utc_offset"=>32400, "profile_text_color"=>"000000", "lang"=>"en", "protected"=>false, "followers_count"=>939, "verified"=>false, "description"=>"来年から社会人の大学生な声オタ。茅原実里/堀江由衣/富樫美鈴/堀中優希/田村ゆかり/白石涼子/佐藤利奈/新谷良子/松来未祐/吉田真弓/藤田咲/木村まどか/阿部玲子。公開中の壁紙：http://tidama.hp.infoseek.co.jp/tw/　since.2007.05.07", "notifications"=>nil, "time_zone"=>"Osaka", "profile_background_color"=>"b8a088", "geo_enabled"=>false, "friends_count"=>581, "statuses_count"=>104141, "profile_background_image_url"=>"http://a1.twimg.com/profile_background_images/2317728/121212.jpg", "following"=>nil, "screen_name"=>"shisetu"}, "in_reply_to_status_id"=>nil}

ふつの API と一緒。ただし、普通の API と違って、 follow してない人への @ も流れてくる。

2. favorite

{"target_object"=>{"id"=>12823149509}, "event"=>"favorite", "target"=>{"id"=>101784326}, "source"=>{"id"=>4301761}}

event の中身が favorite のやつ。見ての通り、 ID でしか流れてこない。 follow してない人の発言や Protected な発言を favorite した場合でも容赦なく流れてくる。これが仕様として問題アリ。

3. follow

{"event"=>"follow", "target"=>{"id"=>100233679}, "source"=>{"id"=>4565971}}

event の中身が follow のやつ。 ID しかこない。 following じゃない人を follow した場合も流れてくる。これも普通に考えて仕様バグ。

4. retweet
{"target_object"=>{"id"=>12824333560}, "event"=>"retweet", "target"=>{"id"=>3557911}, "source"=>{"id"=>25021939}}
event の中身が retweet のやつ。これも ID しかこない。 following じゃない人を retweet した場合も流れてくる。これもおかしい。

4. delete

{"delete"=>{"status"=>{"id"=>12600620062, "user_id"=>5979722}}}

delete の中にごちゃごちゃ入ってるやつ。 user_id が "user_id" な人が status_id が "id" な発言を削除したよ、みたいな奴。仕様はおかしくないが、これが流れてくるのはどう考えても狂ってる(後述)

5. unfavorite

{"target_object"=>{"id"=>9389610133}, "event"=>"unfavorite", "target"=>{"id"=>86054248}, "source"=>{"id"=>15919159}}

favorite を削除した時のやつ。読み方は favorite と同様、仕様バグ。

以上一例です。手元のログから発掘してきました。

この User Streaming ですが、問題点があります。大きく分けて二点。仕様バグがあることと、倫理的におかしいこと。

1. 仕様バグ
favorite follow retweet unfavorite は明らかに仕様の策定ミス。狂っている。 following ではない人の発言を following が favorite したと ID だけで通知されても、 ID から発言を取得する方法が事実上無い(API の実行回数制限により)。 following 、 unfavorite も同様。これにもユーザー情報や status の情報を入れてくれなければ使い物にならない。

現状の仕様では White List を持っていないとどうにもならないので、これは正式リリースまでになんらかの対応(機能が無くなるか、バグが消えるか)がされるでしょう。

2. 倫理面の問題
delete が流れてくるのはどう考えてもおかしい。先述の仕様バグも含め、 firehose をそのままユーザー向けに移植していることが原因と思われる。 firehose であれば delete を API の利用者にリアルタイムで反映してもらう必要があるが、ユーザークライアントでそれをする必要は無いはず。仕様バグの方は firehose ユーザーはそれまでの全発言を持っているので問題無い、ということになる。

こんなものが流れてきても得をするのはネットストーカーだけだ。



めんどくさいから編集してないけど、まあ問題ねえか。実際はもっと際疾い発言が消されているのを観測できたりする。



まとめ
イベントにあわせて firehose 流すのに使ってるのををほぼそのまま無調整で User Streaming に流用していると推測される。いくらなんでもやっつけすぎだし、こんなやっつけ API で「テストをしろ」と開発者に言ってくる Twitter は明らかに狂っている。
それから、 White List に登録された恐しいネットストーカーが発言の削除や favorite の削除すらも監視しているので気をつけましょう。

blog comments powered by Disqus

[ 固定リンク ]