15 ポイント 投稿者 GN⁺ 2025-12-08 | 1件のコメント | WhatsAppで共有
  • RSSフィードベースのウェブ探索拡張機能を制作し、ユーザーが独立系ウェブサイトのコンテンツをランダムに探索して評価できるように実装
  • ボタンをクリックすると新しいサイトを表示し、いいね・よくない・報告機能を通じてコミュニティ主導の推薦構造を形成
  • FastAPIとSQLiteを使ってバックエンドを構築し、Kagiの small web RSSリストを活用して約60万ページをインデックス化
  • 広告やユーザーデータの収集なしで、短時間で興味深いウェブコンテンツを探索する体験を提供
  • 既存のRSSリーダーの疲労感を減らし、小さなウェブ生態系の再発見を目指した個人的な実験プロジェクト

プロジェクト概要

  • RSSリーダーの利用体験が負担だという問題意識から出発
    • 未読記事が積み上がるプレッシャー、時系列コンテンツ構造の非効率性を指摘
    • ユーザーはランダムに興味深い記事を探索したいという欲求を持っている
  • TikTokの推薦方式に着想を得て、小規模ウェブサイトのコンテンツをランダムに提供する構造を設計
    • ユーザーがコンテンツを評価すると、いいね数に応じて露出頻度が増加
    • 広告や個人データ収集なしにシンプルな推薦アルゴリズムを適用

機能とユーザーフロー

  • Firefox拡張機能として提供され、timewasterpro.xyz からダウンロード可能
  • ユーザーはボタンをクリックして新しいウェブサイトを受け取り、Upvote/Downvote/Reportで評価
  • アカウント作成が必要で、投稿したリンクが他のユーザーに人気を得ると Leaderboard で順位が上昇
  • バックエンドでRSSフィードを定期的にクロールしてデータベースに保存
    • 600秒ごとに5件のフィードを確認し、1日1回以下の頻度で更新
    • 報告されたURLはレビュー待ちキューに移動し、いいね・よくないの回数を記録

技術構成

  • FastAPI でAPIを作成し、SQLAlchemy でデータベースを管理
  • データ保存には SQLite を使用
    • すぐに始められ、バックアップも簡単なため、趣味プロジェクトに適している
  • 認証はメールベースのアカウント作成後、リンク検証を行う方式
    • Passkeyログインも試したが、OSS実装の不安定さにより限定的
    • JWT認証を使用しているが、ユーザー体験の面では非効率だと評価
  • Kagi small web GitHubリポジトリのRSSリストをデータソースとして活用

デザインとユーザー体験

  • System.css ライブラリを使って80〜90年代のApple System OS風スタイルを実装
    • 「専門サービスではなく個人的な実験」であることを視覚的に伝達
  • キーボードショートカットをOSごとに分けられず、Altキーに固定
  • 拡張機能の manifest.json 設定で、ブラウザごとのID指定問題に直面
  • 分析ツールを含めていないため、ユーザーフィードバックは直接報告された問題を中心に収集

今後の計画

  • コンテンツをカテゴリ別に分類し、ユーザーが好むジャンルをより頻繁に見られるよう改善予定
  • Downvoteが一定水準を超えたコンテンツを別キューへ移動する機能を検討
  • 新規ユーザーが初期段階で**「良いコンテンツ」を優先的に見られる構造**の整備が必要
  • 写真・科学・工芸分野の独立系ウェブサイトの拡充を希望
  • 現在約60万ページのインデックス化が完了しており、ソースコードは安定化後に公開予定

1件のコメント

 
GN⁺ 2025-12-08
Hacker Newsのコメント
  • すべてのコンテンツを読まなければならないという発想は、リーダーUI設計の欠陥

    • RSSフィードをメールのような「受信トレイ」として見せるやり方が問題だ

    • TikTokのように流れていく**「ニュースの川(river of news)」**として捉えるべきだ

    • 面白い記事だけ少し覗いて、残りはそのまま流してしまうのが肝心だ

    • Twitterも本質的にはRSSに近い構造だった — ただ「未読」表示なしでスクロールする方式だっただけだ

    • だから「未読件数」カウンターはオフにしたほうがいい。RSSの価値は、自分が何を選んで読むかにある

    • 本当に良い記事なら、いずれほかの購読者がリンクを共有してくれるはずだ

    • 私は「川」よりも受信トレイ方式のほうが好きだ

      • フィードをカテゴリ別に整理しておけば、「すべて既読」にするのもそれほど難しくない
      • その代わり、あまりに頻繁に投稿するフィードはすぐ購読解除する。毎日更新するブログは消化しきれない
    • 私もかつて、Web全体から自分の好みに合うコンテンツを自動で見つけてくれるシステムを作ろうとしたことがある

      • 結局、高品質なデータソースの重要性に気づき、少数の良い人だけを購読すればいいという結論に至った
      • 最初から考え直してみると、それこそがRSSだった — 2005年にはすでに完成していた概念だった
    • 私も数年前に似たような気づきを得た

      • 既読の追跡をしたくなかったので、各RSSフィードごとにボットを作ってDiasporaにミラーリングした
      • 今はMastodonに移ったが原理は同じだ — ただスクロールしながら興味のある記事だけを見る方式だ
    • Twitterは「そういう」サービスだった。今は違う

  • RSSリーダーの使い方を間違えている人もいるようだ

    • RSSはYouTubeチャンネルのようにすべてのコンテンツを消費するものではなく、見出しだけ見て興味のある記事だけ読むための道具

    • TikTokはむしろもっと悪い — 終わりのないコンテンツの流れで人を引き留め続ける構造だからだ

    • こういう人は新しいRSSリーダーより、「後で読む」リストを使ったほうがいい気がする

    • TikTokの推薦エンジンは個々のコンテンツ単位で反応を測定するので非常に効率的だ

      • 一方YouTubeは複数のサムネイルから1つを選ばせるため、クリックされなかった9個についての情報を失う
      • アルゴリズムそのものが悪いのではなく、何を最適化するかが問題だ
      • 私のリーダーもTikTokのように一度に1つのコンテンツを見せるが、自分で投稿した科学論文やLLM関連の記事などで構成されている
    • 誰かがRSSを「間違って使っている」と決めつける必要はない

      • コンテンツ消費のスタイルが「今上がってきたものを読む」から「自分で積み上げたものに追いつく」へ変わっただけだ
      • YouTubeも同じ原理で使える
    • 昔NetNewsWireを使っていたとき、未読バッジのせいで不安感を覚えた

      • 今また使うならバッジをオフにして、2日以上経った記事は自動で既読にするだろう
    • 私は2005年版のtt-rssをカスタマイズして使っている

      • あるフィードは最初から最後まで読み、あるフィードはたまに流し見するだけだ
      • 将来的には推薦システムベースのアルゴリズムフィードを追加したい
      • 特に、自分が愛読している書き手の「スター付き/タグ付き記事」をもとにした分散型推薦フィードを試してみたい
    • Google Readerの**「未読」表示**がメールのように見えて、まるで「やるべき仕事」のように感じられた

      • 単に見出しを流し見する行為ではなく、「作業」のように見せてしまうUIだった
  • 多くの人はRSSをWebフィードの一般名詞として使っている

    • 実際の実装では、RSS、Atom、JSON Feedのどれを使うべきかが問題になる

    • ポッドキャストはいまでもRSSを基本として使っている

    • 私はJSON Feedしか使わない

      • シンプルな構造のおかげでたいていのリーダーでうまく動き、プログラムから扱いやすい
      • 自分で生成するときは100% JSON Feedを使う。Atomをわざわざ使う理由を感じたことがない
  • たいていのフィードリーダーは、実際にはRSSを使わない人が作っているように思える

    • 私は211個のフィードを20ほどのカテゴリで管理しており、13,000件のキャッシュ項目がある

    • 実際にクリックして本文を開く割合は1〜5%程度だ

    • 完全に同感だ。フィルタリング機能や大量の記事を処理できる構造がないリーダーが多い

  • RSSの利点は、推薦アルゴリズムの影響を受けないことだ

    • 特定のドメインばかりが繰り返し露出せず、さまざまな分野の記事をバランスよく見られる
    • これは伝統的な線形の情報フローモデルへの回帰のようにも感じられる
  • こういうプロジェクトは本当にうれしい

    • StumbleUponが大好きだったので、似たようなサービスが出てきてうれしい

    • 誰かDIGGの後継を作ってくれたらいいのにと思う

    • まったく同感だ。StumbleUponの懐かしさを感じさせつつ、コンテンツの焦点を自分で選べる点がいい

    • ちなみにDiggは最近ベータ版として再ローンチされた

  • 私はRSSの非アルゴリズム的キュレーションが好きだが、「面白さ」中心のキュレーションは求めていない

    • TikTokのような「エンゲージメント」を促す構造は避けたい
    • RSSをまた使う理由は、自分が好きな著者と直接つながるためだ
    • 後になってコンテンツが多くなったら、アルゴリズムがコンテンツを圧縮してくれる週刊ニュースレター型キュレーションが理想的かもしれない
  • コンテンツの時系列を維持するかどうかは状況次第だ

    • RSSリーダーやポッドキャストでもこの問題を解決するUXを想像してきたが、まだ良い解決策は見つかっていない
  • Scourというサービスを勧める

    • ユーザーの関心や関連性の高い記事を順位付けしてくれる

    • RSSフィードを取り込むか、15,000以上のソースから検索できる

    • 何千件もの「未読」項目を避け、良い記事だけを選んでくれるツールとして設計されている

    • 面白そうだと思う。特定のフィードをブラックリストとして除外できる機能があるのか気になる

  • RSSのカテゴリ分類の問題を解決しようとしている

    • categoryフィールドを使わないフィードが多いので、説明欄のハッシュタグをパースするクローラーを作った

    • 1日ごとにRSSの「inbox zero」を保つため、あまりに頻繁に投稿するブログは購読解除している

    • 投稿頻度とコンテンツ品質は反比例する傾向がある

    • 私はKarakeepアプリでRSSを購読している

      • コンテンツを自動保存し、生成AIでタグを生成する
      • 条件ベースのRSSフィードを作れるので、既存のリーダーと一緒に使いやすい
    • 私のWebサイトでも複数種類のコンテンツを配信しているが、ほとんどのリーダーがcategoryタグをサポートしていないので

      • 結局、タイトルに[Blog]のような接頭辞を付ける方式で区別している