Blueskyのコメント機能を自分のブログに構築する

 (natalie.sh)
1 ポイント 投稿者 GN⁺ 2025-08-08 | 1件のコメント | WhatsAppで共有
  • 既存のコメントシステム（Disqus、セルフホスティング、GitHub Issues など）は、速度、トラッキング、保守負荷、ユーザー制限などの問題で採用していない
  • Blueskyはインフラ維持が不要、リッチコンテンツ対応、実名ベースのアカウント、クロスプラットフォーム対話が可能で、ブログのコメントに適している
  • 実装方法は、ブログ記事を投稿 → Blueskyに共有 → AT URIをブログ投稿のメタデータに追加 → 該当投稿のコメントスレッドを取得して表示する構造
  • コンポーネントは、コメント全体の表示、個別コメント+返信の表示、画像・リンクなど埋め込み処理の3つに分離
  • 再帰方式で最大5段階の返信表示、画像グリッド・モーダル、リンクカード、未対応の埋め込みは代替文言で処理
  • Astro + React統合、client:loadでクライアント側で読み込み、frontmatterにDIDとpostCidを追加して有効化
  • 型安定性確保のために@atcute/client TypeScript型を活用し、JavaScript無効時でも本文が正常表示されるプログレッシブ・エンハンスメント構造
  • サーバー・DBなしでBluesky APIとCDNを活用してパフォーマンスを確保
  • このアプローチは、ソーシャル機能をサイトごとに再実装する代わりに、ユーザーが既に使っているプラットフォームと接続することで拡張性と独立性を確保する

Blueskyをコメントシステムとして選んだ理由

  • インフラ維持が不要
  • 画像・リンク・引用投稿など豊富なコンテンツをサポート
  • Blueskyアカウントベースの信頼性と責任性
  • ブログとソーシャルメディア間でトラフィックの相互流入が可能
  • コンテンツ所有権の分離（ブログ記事は本人、コメントは投稿者所有）

AT Protocolの理解

  • DID: 分散型ユーザー識別子
  • CID: コンテンツ識別子
  • AT URI: at://did:.../app.bsky.feed.post/... 形式のアドレス
  • getPostThread API呼び出しでコメントスレッドを取得可能、認証不要

コンポーネント構成

  • メインコメントコンポーネント
  • 個別コメント+返信レンダリングコンポーネント
  • 画像・リンクなど埋め込み処理コンポーネント

ネストコメントの処理

  • 再帰レンダリング、最大深度5段階の制限
  • 視覚的インデントで階層を表現

リッチコンテンツの処理

  • 画像: CDN提供、複数画像グリッド・モーダルビュー
  • 外部リンク: サムネイル・説明を含むカードレンダリング
  • その他の埋め込み: 代替文言を表示

Astro統合

  • Reactコンポーネント + client:load使用
  • frontmatterにBluesky DID、postCidを追加してコメントを有効化

開発体験

  • TypeScript型サポートで安定性を確保
  • Progressive Enhancementにより、API障害時でも本文への影響なし
  • サーバー・DBの負荷なしでBlueskyインフラを活用

結論

  • 既存のコメントシステムの課題を回避し、ユーザーがすでに使っているプラットフォームと接続
  • Blueskyの成長に伴い参加者の増加が期待できる
  • ATProtoベースのため、他のAppViewや独自実装への移行も容易

関連記事

1件のコメント

 
GN⁺ 2025-08-08
Hacker Newsコメント
  • Blueskyが今後どのように収益化するか、全体的なアイデアを公開してほしい。複雑な技術構造で包まれているように見えるが、最終的に何らかの有料化が進むならどの方式なのか気になる。
  • 興味深い記事だと思う。個人的に、他人が独自にホームページを構築して運営する過程を読むのが好きだ。記事ではコメントシステムの問題点と4つの代替案が挙げられているが、私は5番目の方法も効果があったと付け加えたい。
    複数のサードパーティコメントシステムを試した末、最終的には自作のシンプルなコメントシステム（form.lisp）を作って使っている。各コメントはテキストファイルとして保存されるため、スパムやXSS、無意味なコメントを気にする必要がない。週末ごとに手動で確認してブログに追加する運用をしている。
    コメントは通常のHTMLファイルで保存され、静的サイトジェネレーター（site.lisp）が本文と一緒にコメントページ（コメント例）も生成してくれる。つまり本質的に静的コメントジェネレーターとして動作している。
    記事で言及されている5つの要件（追加インフラ不要、リッチコンテンツ、実名など）には合致しないが、自分には合っていて、4年以上満足して運用している。
    • メールフォームなどでコメントを受け取り、管理者側で記事下部に手動で追加する方式もそれなりに良い。
    • 自分の方法も低トラフィックブログには非常に適していると思う。ただ私は、他人の声が入るのが違和感があるので、コメント自体を外してブログを自分の個性表現の場だけにしている。代わりに、インスピレーションをくれた別のブロガーにはメールでフィードバックを残すのを好んでいる。
    • 新聞の『投稿欄』を受け付けるのに似ていると感じる。
  • 私のおすすめは cactus.chat だ。Matrixベースでゲストもサポートしているため、別途Matrixアカウントがなくてもコメントを書ける。自分のアカウントを使えば、投稿ごとにMatrixルームに参加する形になる。
  • Blueskyは既存のユーザーアカウントベースで情報保存に非常に有用だ。現在はオープンソースのウェブマップ cartes.app でBlueskyベースのレビューシステムを開発中。
    簡単ではなく、lexiconを作ってBlueskyストリームに合わせてDBを継続的に管理しなければならない。
    • 実際、DBなしでも一定程度までは進められる。scrapboard.orgを作っていたときも、getRecord API（ドキュメント）だけでかなりのクライアント側データ取得が可能だった。
    • mangrove.reviewsを使ってみる提案がある。このサービスは明確なCC-BY-SAライセンスが適用され、MapComplete.orgでも使われている。Blueskyにもいずれ問題が起こる可能性はある。
  • Blueskyの収益モデルの持続可能性については懐疑的だ。今無料で使えるのも実質VC投資のおかげだから。
    だから導入には慎重で、近い将来にAPIが閉鎖されたりコメントシステムが壊れたりするのではないかという不安がある。
    • Blueskyはアーキテクチャ上、ユーザーのPersonal Data Server（PDS）の下で動作しており、誰でもPDSを変更できる。公式のBlueskyアプリサーバーは単なる集約役に過ぎない。
      第三者が作ったapp serverやapp viewなどからも同一データにアクセスできるため、わざわざ公式APIに依存する必要はない。いくつかの点で開放性は高い。
    • 自分はPOSSEという概念を強く信じている。『enshittification cycle』の良い面は、一度は快適なオンラインコミュニティ体験を得られて、その後別の場所へ移れたという点だ。昔の良いクラブが消え去ったように、あまり執着しすぎる必要はない。私の考えをまとめたMastodon投稿のリンクもある。理論説明
    • Blueskyが収益化に移行する時期は来るだろうが、AIや他のサービスも最終的には同じくVC資金で動いている。Twitter、Uber、DoorDashなどと同様に、空気が悪化してもVCが新しい裕福さを夢見てお金を投下し続ける限り、その「豊かさ」を存分に享受するのは一種面白い現象だ。
  • Blueskyエコシステムは本当に素晴らしいと思う。以前この方式（Blueskyベースコメントシステム）の事例を見たことがある。
    少し残念なのは、ウェブページごとにBlueskyへ別投稿を出さないとコメントシステムが動作しないこと。webcomponentのようなものがあればなお良いと思う。
    • 記事で「数年間ブログにちゃんとしたコメントシステムを付けられていない」と言っていたが、ブログ全体では2025年の記事が2つだけ見える（そのうち1つは本投稿）。
    • 以前は別のブログがあったのをarchive.orgで確認したことがある。
  • SNSフィードをわざわざ見なくてもソーシャルとやり取りできる方式なので面白い。
    この機能を自分のブログに付けて、直接コメントを書いてもらい、私はこのインターフェース経由でのみBlueskyやその他のソーシャルとやり取りするだけでもよい。
    フィードを開くと結局「ドゥームスクロール」や時間の無駄に陥る場合が多かった。この方式でそうした悪循環を避けつつ、少しはソーシャルメディアとつながれる新しい可能性を感じた。
    • 「フィードを開けば意味のない情報だけが延々と見える」という共感はあるが、そもそもそれが設計上の目的ではなかったはずだという疑念もある。
  • Blueskyが一人でインターネットにもう一度新鮮なアイデアを自由に出せる環境を作ってくれたという感触がある。
    • 実際には、Threadsより統合オプションを少し開放した程度と見なせるだろう。たぶん「オープン・イノベーション」という表現よりATProtoのほうが適切かもしれない。
    • 企業や単一集団に権力や称賛を集中させたくないが、当面のところBlueskyコミュニティは面白い。かつてTwitterのファンだったので、今のBluesky主要ユーザー層にも同種の人々が多いようだ。今後どうなるかは見守る価値がある。
    • 「プラットフォームではなくプロトコル」というスローガンを信奉している。『build mode』という言葉もあるが、結局は誰かに所有されるか悪用されにくいものを作るということだ。
    • Bluesky運営や一部ユーザーグループを刺激したり、特定の集団から通報を受ければアカウントは即座にBANされる可能性がある。あるいは事前共有されたブラックリストに載ると、言葉を発する前に既に見えなくなることもある。
      根本的には、昔のTwitterよりさらに過激な環境を再現しようとする試みのように感じる。まるで高校の給食室のような子どもっぽい権力争い要素もある。
  • ブログを自前でホスティングせずにBlueskyに依存している以上、最終的にはBlueskyで管理していることになる。
    ロックインがないと言われるが、もし明日Blueskyでアカウントがブロックされたり、会社が倒産したりした場合どうするか気になる。
    AT互換製品に切り替えはできるだろうが、データの多くが消えてしまわないか心配だ。
    • このテーマに興味があるなら https://whtwnd.com/bnewbold.net で、BlueskyおよびAT Protoを基盤にした直接リレー構築、データ移行などの実用的な情報やツールが整理されている。データ移行、ポータビリティ、代替リレーサポートなどの各種進展があり、関連リンクも参照できる。
      （参考までに、このブログの著者はBluesky従業員で、私は別人だ）
    • 自分の個人データはIPFSでCARファイル（tarball形式）としてバックアップでき、その後はアカウントのdid:plc文書やDNSレコードを通じてどのPDSでも復元できる。
      現在のPDSが壊れるかブロックされた場合も、すぐ別サーバーへ移行できる。
      リレー（gossipノード）、PDS、クライアント、アプリビュー（Blueskyウェブアプリのバックエンド）などの各種オープンソース実装とホスティング提供者が存在する。
      Blueskyが明日壊れても、自分でホスティングするか、別業者（例：zeppelin.social）を使って既存アプリを継続できる。
      PLCディレクトリはまだBlueskyが管理しているが、独立財団へ移行中で、必要なら複製も容易。did:web方式を使えばDNS体系のみに依存するため独立性が高い。
    • さらに言えば、Blueskyは明確にリバタリアン（自由主義）あるいは右派傾向のユーザーを積極的に排除しており、左派や政治的に無関心な層は比較的良い雰囲気だ。