荒削りだけど何とかAPIの有償化に間に合ったー！　肝心の実験が思うように進まないものだから実験が未完のままでも投稿するつもりでdisclaimerを書き連ねていたけど、ギリギリでそれらしい結果が出たので何とか最低限の体裁が整った（ひどいオチが付いているけど……）

まさか$-100にまで価値が落ちるとは流石に予想しえなかった（？）
QT: https://fedibird.com/@tesaguri/109721301319505660 [参照]

まあ何はともあれこれで心おきなくTwitter APIに別れを告げられる（いや、まだやり残したことはあるけど……）

Twitter APIにおけるタイムラインの取得漏れ問題――前編：原理と対策
https://zenn.dev/tesaguri/articles/leaky-snowflake-theory
TwitterのSnowflake IDは完全な投稿時刻順でなくk-sortedであり、IDが時刻順であることをを仮定した`since_id`パラメータの設定によりタイムラインのポーリングにおいてツイートを取りこぼしうるという問題提起と、その解決法の提案を行う記事です。ちなみにSnowflakeの仕組みはMastodonでも使われています。 #Twitter #TwitterAPI

Your Timelines Are Leaky: A Slipperiness of Twitter's Snowflake IDs and `since_id` ❄️
https://github.com/tesaguri/leaky-snowflake/blob/main/README.md
#Twitter 's Snowflake IDs (akin to Mastodon's post IDs) are k-sorted instead of complete chronological order. Apps polling timelines may thus miss Tweets by setting the `since_id` parameter on the assumption of the chronological order. This article demonstrates the mechanism of and a solution to the problem. #TwitterAPI

宣伝慣れしていなくて、そういえばハッシュタグを付け忘れていたので恥を忍んで再投稿

これはどちらかというとむしろミュートされる類のハッシュタグでは？

MastodonのAPI向けのコード例を書いていて思ったけど、Mastodonのタイムラインに対するポーリングはどうやるのが正しいのかしら。脚注でも触れたとおり、Mastodonの場合は特に`since_id`では不十分な気がするけど

単にソートして表示するだけの用途とかなら投稿時刻によるSnowflake IDで良いけど、ポーリングにおいて必要なのはサーバに到達した順のcursorだよね。しかしドキュメントをざっと眺めた感じだとそれらしいものが見当たらない

Twitter APIをメインに扱っておまけとしてMastodon APIにも適用するという構成を取ってしまったけど、じきに$-100の価値になるAPIをメインとするより今後発展していくであろうAPIをメインに据えるべきだったかもしれないな（？）

結局Cookieを隔離した上でZennを使うことにしたけど、やはりGoogleアカウントの扱いが面倒なので早く別の手段が提供されてくれると嬉しい
QT: https://pawoo.net/@dmiz/109635986386583291 [参照]