ハクソク

世界を動かす技術を、日本語で。

ブログのための「Bluesky」コメントの作成

291日前原文(natalie.sh)

概要

  • 従来のコメントシステム（Disqus等）の問題点と限界を指摘
  • BlueskyのAPIとAT Protocolを活用した新しいコメント導入事例
  • 実装アーキテクチャ、リッチコンテンツ対応、Astroとの統合方法を解説
  • TypeScript活用やパフォーマンス面での利点を整理
  • このアプローチの今後の展望と分散型Webの意義を考察

従来のコメントシステムへの不満

  • Disqus は動作が遅く、重く、ユーザートラッキングや所有権の問題がある
  • ページの読み込み速度が著しく低下するデメリット
  • 自前ホスティング 型コメントは、ユーザー管理・スパム対策・DB運用などの負担が大きい
  • GitHub Issues をコメント化する方法は開発者向けで、一般的な読者にはハードルが高い
  • コメント機能自体を廃止すると、 議論や発見の機会 を失うリスク

Blueskyを使ったコメントシステムの発想

  • Bluesky コミュニティの健全さやAPI設計、分散型の特性に着目
  • Bluesky上でブログ記事を共有し、その投稿への リプライをブログコメントとして利用 するアイデア
  • インフラ管理やユーザー管理が不要で、 Bluesky側に任せられる 利便性
  • 画像やリンクなどの リッチコンテンツ対応、実名性による荒らし抑止
  • コメントがBlueskyにも残ることで、 クロスプラットフォームな議論 が可能
  • 各自が自分のコンテンツを所有し、 プラットフォームロックイン が起きない設計

実装アーキテクチャ

  • AT Protocol の理解が必須

    • DID （分散型ID）: 例 did:plc:abc123...
    • CID （コンテンツID）: 投稿固有の識別子
    • AT URI: 例 at://did:plc:user.../app.bsky.feed.post/postid

  • コメント取得は getPostThreadエンドポイント を利用、認証不要

  • コンポーネント構成

    • メインコメントコンポーネント: スレッド取得・表示
    • リプライコンポーネント: 個別返信やメタ情報、Bluesky元投稿へのリンク
    • 埋め込みコンポーネント: 画像やOGPプレビュー等リッチメディア対応

  • スレッドの深さ は最大5階層に制限し、再帰的に表示

    • const MAX_DEPTH = 5;
const BlueskyReply = ({ thread, depth = 0 }) => {
  return (
    <div style={{ marginLeft: depth * 12 }}>
      {/* 投稿内容表示 */}
      {depth < MAX_DEPTH && thread.replies?.map(reply =>
        <BlueskyReply thread={reply} depth={depth + 1} />
      )}
    </div>
  );
};

リッチコンテンツ対応

  • 画像埋め込み: Bluesky CDN経由で複数画像をグリッド表示、モーダルで拡大
  • 外部リンク: サムネイル・説明付きカードで表示
  • 未知の埋め込み型: プロトコル拡張性を考慮し、未対応時はフォールバック表示

Astroとの統合

  • 既存の React統合 を活用し、client:loadで即時ハイドレーション

  • フロントマターで下記のように設定

    • bsky:
  did: "my-bluesky-did"
  postCid: "the-post-id"

  • 対象記事にのみコメント機能を有効化可能

実装から得た知見

  • TypeScript型 が公式パッケージ（@atcute/client）で提供されており、開発効率向上
  • プログレッシブエンハンスメント: JSやAPIが使えなくても記事は読める
  • パフォーマンス: バックエンド管理不要、CDN・APIキャッシュ活用で高速
  • コメント体験が より自然でソーシャル的 になった実感

このアプローチの意義と今後

  • 従来のコメント欄は SNSの機能を各ブログで再発明 していた
  • 読者が既に使っているSNSアカウントで参加できる利便性
  • Blueskyの成長に合わせて自動的にスケール、自分は追加作業不要
  • オープンプロトコル基盤のため プラットフォーム依存からの自由
    • 例えばBlueskyが変質しても、他のAppView（zeppelinやBlacksky等）へ移行可能
    • ATProto の柔軟性を活かし、独自AppView作成も容易
  • 独立サイトが 分散型Webの広い会話圏 と繋がる理想的な形
  • Mastodon等の他分散型SNSよりも、 ユーザーIDの所有・相互運用性 で優位性
  • 実際の動作例は本記事下部のコメント欄で確認可能

メタ: 本記事のコメント欄もBluesky連携システムで稼働

Hackerたちの意見

Blueskyのエコシステム、めっちゃクールだね！前にここで紹介されてたアプローチを読んだことあるよ。ただ一つ問題があるとしたら、全てのウェブページでコメントシステムを使うには、Blueskyに投稿しなきゃいけないことかな。これのためのウェブコンポーネントがあったらいいな。

これは素晴らしいアイデアだね！コメントの問題を解決するだけじゃなくて、みんながBlueskyで会話を続けられるようになるし。よくやった！

これについて気になるのは、コメントのモデレーションをどうするかってことだな。スパムや失礼なコメントを削除するの？

└

Mastodonのコメントについては、簡単な方法が2つあるよ： - 自分がモデレートしているインスタンスでコメントを運営する - さらに良いのは、自分のアカウントがお気に入りにしたコメントだけを表示すること。最後の詳細はここにあるよ： https://hci.social/@ryanatkn/111983960076822015

└

Blueskyではスレッドの所有者がスレッドから投稿を隠すことができるんだ。おそらくブログのインターフェース自体が、隠された返信を全く表示しないように選ぶこともできるし、別のクライアント（例えばBlueskyアプリ）でスレッドを表示すると、隠された投稿を見るオプションがあるよ。もちろん、自分のBlueskyインターフェースを通してスレッドを見ると、個人のブロックリストやモデレーションが適用される。

└

これが実装されてるかは分からないけど、Blueskyには返信を隠すためのAPI（スレッドゲーティングって呼ばれてる）があるんだ。ただ、これは別のAPIコールだから、APIを通してスレッドを読み込むときに自動的には得られないよ。俺も同じ目的のためにウェブコンポーネントを作ったから、そこでスレッドゲーティングをどう実装したか見てみて： https://github.com/ascorbic/bluesky-comments-tag

Blueskyが一手にインターネットを新しいアイデアのためにオープンにしている感じがするね。

└

「プロトコル、プラットフォームではなく。」子供たちが言うように、「ビルドモード」だけど、捕まえられないものを作るって感じ。

└

一つの企業や団体に過剰に評価するのはためらうけど、少なくとも今のところ、BlueSkyのコミュニティは結構楽しいよ。正直、昔のTwitterが好きだったし、今アクティブなのはその層みたいだね。これからどうなるか見てみよう。

└

もちろん、BSのモデレーターたちを怒らせるようなことを言ったり、特定のユーザーグループに大量通報されたりしたら、すぐにアカウントがバンされるよ。さらに悪いことに、事前に共有されたブラックリストに載っちゃったら、何も言う前から見えなくなる。BSは、昔のTwitterよりもさらに毒性の強い環境を再現しようとしてる感じ。まるで高校のカフェテリアのドラマみたいだね。

BlueSkyの収益性にはあまり楽観的じゃないな。今の無料で使えるのはVCの資金提供の結果だし、個人的には採用するのに慎重になってる。APIが制限されて、数年後にはコメントが壊れる可能性が高いと思う。

└

https://indieweb.org/POSSE を信じてるし、「エンシティフィケーションサイクル」の明るい面は、しばらくの間いい場所ができて、その後は移動できることだと思う。もうMudd ClubやCBGBでパーティーする人はいないし、なんでそんなことをする必要があるの？ 理論については https://mastodon.social/@UP8/114988462585487831

└

BlueskyはPDS（個人データサーバー）の下流に設計されてるから、ユーザーは別のプロバイダーに切り替えられるんだ。Blueskyのアプリサーバーは集約器として機能してるけど、他の誰でも自分の集約器を作れるし、実際にそうしてる人もいるよ。だから、ナタリーが投稿で言ってるように、投稿にアクセスするのにBlueskyのアプリAPIを使う「必要はない」んだ。サードパーティのアプリサーバーから（「アプリビュー」）取得することもできるし、自分のものを持つこともできるよ。みんな同じデータソースから集約してるからね。

あなたがホスティングしているわけじゃないから、たぶんBlueSkyがやってるんだよね。プラットフォームのロックインはないって言ってるけど、もし明日BlueSkyにバンされたらどうするの？明日BlueSkyが倒産したら？他のAT準拠の製品に切り替えられると思うけど、かなりのデータが消えちゃうよね？

└

それに加えて、BlueSkyはリバタリアンや右寄りのユーザーを結構追い出してるよね。左寄りか政治的に無関心な人たちは大丈夫みたい。

└

このトピックを詳しく理解したいなら、https://whtwnd.com/bnewbold.net には自分のリレーネットワークを運営したり、データを移行したりする情報があるよ。データ移行やポータビリティ、代替リレーネットワークに関する作業が続いてる。特に https://whtwnd.com/bnewbold.net/3lbvbtqrg5t2t は関連性が高いよ。（ブログの著者はBlueSkyで働いてるけど、個人的な関係はない）

└

そう。自分の個人データを実質的に高級なtarボールにバックアップできる（技術的にはIPFSが使うCARファイルのコレクションみたいなもの）。それをPDS（個人データサーバー）に復元できるんだ。アカウントをそこに向ければ（did:plcドキュメントかdid:webのDNSレコード経由で）。だから、今のPDSが崩壊したりバンされたりしても、他の場所に行けばいいんだよね。もちろん、リレー（ゴシップノード）、PDSの実装、クライアント、アプリビュー（BlueSkyのウェブアプリのサーバーバックエンド）用のいくつかの実装やホストがあるから、厳密に言えば、明日BlueSkyが崩壊しても、同じアプリの自己ホスト版を使ったり、他の誰かのを使ったりできるよ（例えば https://zeppelin.social みたいに）。PLCディレクトリはまだ技術的にはBlueSkyの手にあるけど、今は独立した財団に移行中で、必要なら簡単にフォークできる。もちろん、did:webを使っているなら、それは関係ないし、DNSに依存するだけだよ。

「数年にわたって、まともなコメントなしでブログを運営してきた。ブログ全体で2つの投稿しか見えないけど、どちらも2025年のもので（そのうちの1つがこの投稿）。」

└

archive.orgによると、彼らは別のブログも持ってたみたい。

面白い記事だね！人々が独自の個人ウェブサイトを作って維持する様子を読むのはいつも楽しい。この記事は「コメントシステムの問題」から始まって、4つの解決策を挙げてるけど、実は私には5つ目の解決策があって、それがうまくいってるんだ。サードパーティのコメントシステムに時間をかけすぎた結果、自分で作ったんだよ[1]。かなりシンプルで、必要なことだけをやってくれる。各コメントは手動レビューのためにテキストファイルに書き込まれるから、スパムやクロスサイトスクリプティング、無関係なコメントを心配しなくて済む。週末にチェックして、ブログに追加することが多いかな。コメントはプレーンHTMLファイルとして保存されていて、私の静的サイトジェネレーター[2]がサイトとコメントページ[3]を一緒に作成してくれる。だから、ある意味では静的コメントページジェネレーターでもあるんだ。この設定は、記事の第2セクションにある5つの属性（インフラなし、リッチコンテンツ、実際のアイデンティティなど）には合わないから、著者のニーズには合わないと思うけど、私にはかなりうまくいってる。少なくとも4年間は使ってるし（もっと長いかも、古いPHPサイトでも似たようなことをしてたから）、満足してるよ。

└

コメントを（メール）フォーム経由で受け取って、それを手動で記事のHTML/Markdownの下に追加するのはいいね。

└

あなたの解決策、いいね！低トラフィックのブログには完璧だと思う。個人的には、コメントは面倒だと思ってるから、サイトにはわざと含めてないんだ。私のブログは私の個性の表現だから、他の人の言葉が私のページに現れるのは変に感じる。人々がフィードバックを楽しむのは知ってるから、無意味なコメントを残す代わりに、好きなブログのブロガーにメールを送るようにしてるよ。

└

新聞の「編集者への手紙」みたいな感じだね（：

Blueskyはユーザーの既存アカウントに関する情報を保存するのにとても便利だよ。今、Blueskyを基にしたオープンソースのWebマップ https://cartes.app のレビューシステムを作ってるんだけど、簡単じゃないよ。レキシコンを作成して、Blueskyのストリームに基づいたDBを維持する必要があるから。

└

自分のDBなしでもかなりのところまで行けるよ。必要なクエリの種類によるけど。私のプロジェクト[1]では、クライアントサイドで取得する必要があるデータの多くにgetRecord[2]を使えたよ。 1 - https://scrapboard.org/ 2 - https://docs.bsky.app/docs/api/com-atproto-repo-get-record

ActivityPubがWordpressについて、Blueskyとのブリッジに関する記事を投稿したよ！ https://activitypub.blog/2025/08/07/bridging-the-gap/