blogtato - Git で同期する Taskwarrior 風 RSS reader
RSS reader には、よくある方向が 2 つあります。ひとつは Feedly や Inoreader のような hosted service で、sync や mobile experience が楽です。もうひとつは FreshRSS、Miniflux、Tiny Tiny RSS のような self-hosted service で、data control はしやすい一方、常時動く service を保守する必要があります。
今日紹介する kantord/blogtato は、そのどちらとも少し違います。Rust 製の CLI RSS/Atom reader で、interface と query style は Taskwarrior に影響を受けています。Data は JSONL file として保存され、必要なら Git で複数 machine 間に同期できます。Account も常駐 server も不要で、reading flow を browser tab に閉じ込める必要もありません。
公開時点の GitHub page では、およそ 226 stars、4 forks。主な言語は Rust、license は Apache-2.0 です。Project は 2026-02 に作成され、現在も更新されています。Latest release は v0.1.25、公開日は 2026-05-13 です。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| Repository | kantord/blogtato |
| 位置づけ | CLI RSS/Atom feed reader |
| Stars | 約 226 |
| Forks | 4 |
| 主な言語 | Rust |
| License | Apache-2.0 |
| Latest release | v0.1.25 |
RSS を command-line task list のように扱う
blogtato の特徴は、RSS reader を小さな web application として作らず、information stream を command-line object として扱っているところです。
Install 後は、blog feed add で feed を追加し、blog sync で新しい item を取得し、blog で default list を表示します。Default view は直近 3 か月の unread posts を表示し、week ごとに group します。必要に応じて date、week、feed ごとの grouping に切り替えられます。
この interaction は task list の処理に近いです。「content center」を開くのではなく、terminal 上で entry を filter し、open し、read として mark し、export します。毎日 shell の中で作業している人には、web reader に切り替えるより軽く感じられます。
Query language が中心体験になっている
README の例を見ると、blogtato の焦点がわかります。単に list と read を持つだけでなく、短い query で feed、read status、time range、grouping を組み合わせます。
たとえば feed shorthand で filter でき、.unread、.read、.all で status を切り替えられます。Time range は 1w.. や 3m..1m のように書けます。Grouping は /d、/w、/f で制御します。組み合わせると、「Hacker News の unread item だけを date ごとに見る」といった日常的な指定を短く表現できます。
これは traditional RSS reader の folder tree より、command-line filter に近い考え方です。rg、fd、jq、Taskwarrior、shell pipeline に慣れている user なら、まず集合を絞り込み、その結果に open、mark read、export を適用する流れが自然に感じられるはずです。
Git sync が解決するのは「保守を増やさない」こと
blogtato の sync design には、はっきりした trade-off があります。Data store は JSONL file です。複数 device で同期したい場合は、それを private Git repository に置き、blog sync で feed 取得と remote sync をまとめて行います。
Performance の観点では、README もこれが最適な database design ではないと認めています。ただし目的は high-performance backend を作ることではありません。CLI user が別の service を保守せずに済むようにすることです。GitHub、GitLab、Forgejo のような remote repository をすでに持っているなら、subscription、read status、configuration を他の machine に運べます。
重要なのは、project が conflict-free merge を強調している点です。複数 machine で reading state が分岐しても、user が手動で Git conflict を解く必要はありません。ここでの Git は、reading action を code change として扱わせるものではなく、sync transport layer に近い役割です。
Offline と手動 network access が静かな体験を作る
多くの RSS tool は、常駐し、定期 refresh し、notification を出します。blogtato は逆です。Network operation は user が明示的に開始します。常時動く server は不要で、network access が不要な操作は offline で動きます。
この design は、「読みたいときだけ読む」information flow に合います。未読数を自動で押し出さず、background process も増やしません。1 日の決まった時間に blog sync を実行し、見る価値のあるものだけを filter し、残りを terminal の外に置いておけます。
README にある subscription detox という考え方は、ここに現れています。より多くの recommendation や notification で attention を取るのではなく、RSS を query でき、mark でき、export できる local dataset に戻します。
OPML import で移行の負担を下げる
新しい RSS reader は、既存の subscription を受け取れないと試しにくい。blogtato は OPML file からの import をサポートしているため、Feedly、Inoreader、NetNewsWire、FreshRSS、Feeder、Tiny Tiny RSS、Outlook などから feed list を移せます。
これにより、段階的に試せます。まず OPML を import して local single-machine mode で使う。Command-line workflow が合うと感じたら Git sync を設定する。README でも Git sync は optional とされており、remote を設定しなくても blog sync は feed を取得できます。
つまり、最初から reading system 全体を移行すると決める必要はありません。Offline で scriptable な RSS terminal client として 1 週間試す方が、この tool の性格に合っています。
JSONL export は二次処理に向いている
blogtato は、query に match した post を JSONL として export できます。普通の reader user には目立たない機能かもしれませんが、developer には便利です。
.all export、特定 feed の export、ある time range の export を、他の tool に渡せます。Personal knowledge base への import、reading report の生成、技術記事 list の保存、長く役に立っていない feed の統計などに使えます。
それらの二次処理をすべて built-in UI に詰め込むのではなく、structured data を外に出す。これはかなり Unix 的な選択です。Tool 自体は狭く保ち、composition は shell、jq、自分の script に任せます。
ingest filter は細かく整えたい user の入口
README には、もうひとつ面白い設定があります。ingest_filter です。blog sync が post を保存する前に、jq expression で post object を filter または rewrite できます。
Typical use case は、sponsored content を title で除外する、tracking parameter を link から消す、feed data を軽く normalize する、といったものです。Arbitrary shell script ではなく jq を選んでいるのも自然です。Feed item は structured JSON なので、jq expression の方が複数 machine に同期しやすく、local script path への依存も減ります。
ここにも blogtato の target user が表れています。数 click ですべてを設定する万人向け tool ではなく、小さな tool で input stream を整えたい user に向いた設計です。
先に試す価値がある人
blogtato をまず勧めたいのは、次のような人です。
- 日常的に terminal で作業し、RSS も command-line workflow に入れたい。
- FreshRSS / Miniflux のような service は保守したくないが、複数 device で read status を同期したい。
- Folder と button より、Taskwarrior 風の短い query が好き。
- Subscription content を JSONL として export し、自分の script や knowledge base に渡したい。
- Early-stage tool の境界を理解し、Cargo install と local data directory の管理を受け入れられる。
一方で、成熟した mobile app、full-text fetching、web reading experience、shared team use、複雑な rule engine、commercial service level の sync が必要なら、blogtato は代替ではありません。RSS を local queryable data にし、Git で十分に簡単な sync を行う、狭く静かな personal tool です。
まとめ
kantord/blogtato の価値は、RSS を再発明することではありません。RSS を developer が慣れている toolchain に戻すことです。Subscription は feed、article は filter できる entry、state は local data、sync は Git、export は JSONL です。
Reader の notification、unread anxiety、また別の account system に疲れている一方で、RSS の open nature は残したいなら、blogtato は試す価値があります。すべての人の main reader にはならないかもしれませんが、information flow を静かにし、scriptable にしたい terminal user にはよく合います。