{"id":23310290,"url":"https://github.com/dahlia/fedify-microblog-tutorial-ja","last_synced_at":"2025-10-25T23:45:28.012Z","repository":{"id":262370669,"uuid":"868118908","full_name":"dahlia/fedify-microblog-tutorial-ja","owner":"dahlia","description":"『自分だけのフェディバースのマイクロブログを作ろう！』のAsciiDocのソースコード","archived":false,"fork":false,"pushed_at":"2024-12-23T03:32:39.000Z","size":5961,"stargazers_count":20,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-10-24T01:44:46.044Z","etag":null,"topics":["fedify","japanese","microblog","tutorial"],"latest_commit_sha":null,"homepage":"https://github.com/dahlia/fedify-microblog-tutorial-ja/releases/download/2024-12-23/fedify-microblog-tutorial-ja.pdf","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"cc-by-sa-4.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/dahlia.png","metadata":{"files":{"readme":"README.adoc","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-10-05T14:25:29.000Z","updated_at":"2025-06-29T20:41:33.000Z","dependencies_parsed_at":"2024-11-12T04:24:50.014Z","dependency_job_id":"b0413fbc-1895-4fa3-b987-a770705932ae","html_url":"https://github.com/dahlia/fedify-microblog-tutorial-ja","commit_stats":null,"previous_names":["dahlia/fedify-microblog-tutorial-ja"],"tags_count":3,"template":false,"template_full_name":null,"purl":"pkg:github/dahlia/fedify-microblog-tutorial-ja","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dahlia%2Ffedify-microblog-tutorial-ja","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dahlia%2Ffedify-microblog-tutorial-ja/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dahlia%2Ffedify-microblog-tutorial-ja/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dahlia%2Ffedify-microblog-tutorial-ja/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/dahlia","download_url":"https://codeload.github.com/dahlia/fedify-microblog-tutorial-ja/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dahlia%2Ffedify-microblog-tutorial-ja/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":281038752,"owners_count":26433646,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-10-25T02:00:06.499Z","response_time":81,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["fedify","japanese","microblog","tutorial"],"created_at":"2024-12-20T13:17:17.062Z","updated_at":"2025-10-25T23:45:27.979Z","avatar_url":"https://github.com/dahlia.png","language":"Shell","funding_links":[],"categories":["Shell"],"sub_categories":[],"readme":"= 自分だけのフェディバースのマイクロブログを作ろう！\n:author: 洪 民憙（ホン・ミンヒ）\n:email: hong@minhee.org\n:doctype: book\n:lang: ja\n:scripts: cjk\n:experimental:\n:imagesdir: ./images\n:toc:\n:toc-title: 目次\n:figure-caption: 図\n:tip-caption: ヒント\n:note-caption: 注釈\n:important-caption: 重要\n:caution-caption: 注意\n:warning-caption: 警告\n\n== 序文\n\n[TIP]\n====\n本書はAsciiDocで組版されており、​以下のGitHubリポジトリからソースコードとPDF本を入手できます：\n\n\u003chttps://github.com/dahlia/fedify-microblog-tutorial-ja\u003e\n====\n\nこのチュートリアルに入る前に、​フェディバースとActivityPubについて簡単に説明しましょう。\n\n=== フェディバースとは？\n\nlink:https://ja.wikipedia.org/wiki/Fediverse[フェディバース]（fediverse）は、​“federation”（連合）と“universe”（宇宙）を組み合わせた造語で、​相互にやり取りができる分散型のソーシャルネットワークの集合体を指します。​従来の中央集権型のソーシャルメディアプラットフォーム（例：X、​Facebook）とは異なり、​フェディバースは多数の独立したサーバー（インスタンス）で構成されています。\n\nフェディバースの主な特徴：\n\n- **分散型**：単一の企業や団体が管理するのではなく、​世界中の個人や組織が運営する多数のサーバーで構成されています。\n- **相互運用性**：異なるサーバー上のユーザーが相互にコミュニケーションを取ることができます。\n- **オープンソース**：多くのフェディバースソフトウェアはオープンソースで、​誰でも自由に使用​・​改変できます。\n- **データの自己管理**：ユーザーは自分のデータをより直接的に管理できます。\n\nフェディバースの代表的なソフトウェアには、​link:https://joinmastodon.org/ja[Mastodon]、​Metaのlink:https://www.threads.net/[Threads]、​link:https://misskey-hub.net/ja/[Misskey]、​link:https://pixelfed.org/[Pixelfed]などがあります。\n\n=== ActivityPubとは？\n\nlink:https://activitypub.rocks/[ActivityPub]は、​​フェディバースを支える重要な技術標準の一つです。​​これは、​​ソーシャルネットワーキングプロトコルであり、​​異なるサーバー間でのアクティビティ（投稿、​​コメント、​​いいね等）の共有方法を定義しています。\n\nActivityPubの主な特徴：\n\n- **W3C勧告**：World Wide Web Consortium（W3C）によって標準化されています。\n- **クライアント-サーバー通信**：ユーザーのクライアントアプリとサーバー間の通信を定義します。\n- **サーバー間通信**：異なるサーバー間でのアクティビティの配信方法を規定します。\n- **JSON-LD形式**：データはJSON for Linked Data （JSON-LD）形式で表現されます。\n\nActivityPubを採用することで、​異なるソフトウェア間での相互運用性が実現され、​ユーザーは自分の選んだサービスを使いながら、​他のサービスのユーザーとコミュニケーションを取ることができます。\n\nこのチュートリアルでは、​ActivityPubサーバーフレームワークであるlink:https://fedify.dev/[Fedify]を使用して、​link:https://joinmastodon.org/ja[Mastodon]やlink:https://misskey-hub.net/ja/[Misskey]のようなActivityPubプロトコルを実装するlink:https://ja.wikipedia.org/wiki/%E3%83%9F%E3%83%8B%E3%83%96%E3%83%AD%E3%82%B0[マイクロブログ]（microblog）を作成します。​ このチュートリアルは、​Fedifyの基本的な動作原理を理解するよりも、​Fedifyの活用方法により焦点を当てています。\n\n=== Fedifyとは？\n\n.Fedifyのロゴ\nimage::logo.svg[Fedifyのロゴ,width=50%,align=center]\n\nlink:https://fedify.dev/[Fedify]は、​ActivityPubやその他の標準規格を利用した連合サーバーアプリを作る為のTypeScriptライブラリです。​ 連合サーバーアプリを作る際の複雑さやボイラプレートコードを排除し、​ビジネスロジックやユーザーエクスペリエンスに集中できる様にすることを目的としています。\n\nFedifyプロジェクトについてもっとお知りになりたい方は、​以下の資料をご覧ください：\n\n- **ウェブサイト**：\u003chttps://fedify.dev/\u003e\n- **GitHub**：\u003chttps://github.com/dahlia/fedify\u003e\n- **APIリファレンス**：\u003chttps://jsr.io/@fedify/fedify\u003e\n- **使用例**：\u003chttps://github.com/dahlia/fedify/tree/main/examples\u003e\n\nご質問、​ご提案、​フィードバックなどございましたら、​お気軽にlink:https://github.com/dahlia/fedify/discussions[GitHub Discussions]にご参加いただくか、​フェディバースのlink:https://hollo.social/@fedify[@fedify@hollo.social]（日本語対応）までご連絡ください！\n\n=== 対象読者\n\nこのチュートリアルは、​Fedifyを学んでActivityPubサーバーソフトウェアを作ってみたい方を対象としています。\n\nHTMLやHTTPを使用してウェブアプリケーションを作成した経験があり、​コマンドラインインターフェース、​SQL、​JSON、​基本的なJavaScriptなどを理解していることを前提としています。​ ただし、​TypeScriptやJSX、​ActivityPub、​Fedifyについては、​このチュートリアルで必要な範囲で説明しますので、​知らなくても大丈夫です。\n\nActivityPubソフトウェアを作成した経験は必要ありませんが、​MastodonやMisskeyのようなActivityPubソフトウェアを少なくとも1つは使用したことがあることを想定しています。​ そうすることで、​私たちが何を作ろうとしているのかをイメージしやすくなります。\n\n=== 目標\n\nこのチュートリアルでは、​Fedifyを使用してActivityPubを通じて他の連合ソフトウェアやサービスと通信可能な個人用マイクロブログを作成します。​このソフトウェアには以下の機能が含まれます：\n\n- ユーザーは1つのアカウントのみ作成できます。\n- フェディバース内の他のアカウントがユーザーをフォローできます。\n- フォロワーはユーザーのフォローを開始したり、​やめたりできます。\n- ユーザーは自分のフォロワーリストを閲覧できます。\n- ユーザーは投稿を作成できます。\n- ユーザーの投稿はフェディバース内のフォロワーに表示されます。\n- ユーザーはフェディバース内の他のアカウントをフォローできます。\n- ユーザーは自分がフォローしているアカウントのリストを閲覧できます。\n- ユーザーは自分がフォローしているアカウントが作成した投稿を時系列順のリストで閲覧できます。\n\nチュートリアルを単純化するために、​以下の機能制約を設けています：\n\n- アカウントプロフィール（自己紹介文、​画像など）は設定できません。\n- 一度作成したアカウントは削除できません。\n- 一度投稿した内容は編集や削除ができません。\n- 一度フォローした他のアカウントのフォローを解除することはできません。\n- いいね、​共有、​コメント機能はありません。\n- 検索機能はありません。\n- 認証や権限チェックなどのセキュリティ機能はありません。\n\nもちろん、​チュートリアルを最後まで進めた後で機能を追加することは自由です。​それは良い練習になるでしょう。\n\n完成したソースコードはlink:https://github.com/dahlia/microblog[GitHubリポジトリ]にアップロードされており、​各実装段階に応じてコミットが分かれていますので、​参考にしてください。\n\n== 開発環境のセットアップ\n\n=== Node.jsのインストール\n\nFedifyはJavaScriptランタイムとしてlink:https://deno.com/[Deno]、​link:https://bun.sh/[Bun]、​link:https://nodejs.org/[Node.js]の3つをサポートしています。​その中でもNode.jsが最も広く使われているため、​このチュートリアルではNode.jsを基準に説明を進めていきます。\n\nTIP: JavaScriptランタイムとは、​JavaScriptコードを実行するプラットフォームのことです。​ウェブブラウザもJavaScriptランタイムの一つであり、​コマンドラインやサーバーではNode.jsなどが広く使われています。​最近ではlink:https://workers.cloudflare.com/[Cloudflare Workers]のようなクラウドエッジ機能もJavaScriptランタイムの一つとして注目を集めています。\n\nFedifyを使用するにはNode.js 20.0.0以上のバージョンが必要です。​link:https://nodejs.org/ja/download/package-manager[様々なインストール方法]がありますので、​自分に最適な方法でNode.jsをインストールしてください。\n\nNode.jsがインストールされると、​``node``コマンドと``npm``コマンドが使えるようになります：\n\n[source,console]\n----\n$ node --version\n$ npm --version\n----\n\n=== ``fedify``コマンドのインストール\n\nFedifyプロジェクトをセットアップするために、​``fedify``コマンドをシステムにインストールする必要があります。​link:https://fedify.dev/cli#installation[複数のインストール方法]がありますが、​``npm``コマンドを使用するのが最も簡単です：\n\n[source,console]\n----\n$ npm install -g @fedify/cli\n----\n\nインストールが完了したら、​``fedify``コマンドが使用可能かどうか確認しましょう。​以下のコマンドで``fedify``コマンドのバージョンを確認できます。\n\n[source,console]\n----\n$ fedify --version\n----\n\n表示されたバージョン番号が1.0.0以上であることを確認してください。​それより古いバージョンだと、​このチュートリアルを正しく進めることができません。\n\n=== ``fedify init``でプロジェクトの初期化\n\n新しいFedifyプロジェクトを開始するために、​作業ディレクトリのパスを決めましょう。​このチュートリアルでは__microblog__と名付けることにします。​``fedify init``コマンドの後にディレクトリパスを指定して実行します（ディレクトリがまだ存在しなくても大丈夫です）：\n\n[source,console]\n----\n$ fedify init microblog\n----\n\n``fedify init``コマンドを実行すると、​以下のような質問プロンプトが表示されます。​順番にmenu:Node.js[npm \u003e Hono \u003e In-memory \u003e In-process]を選択します：\n\n[listing]\n----\n             ___      _____        _ _  __\n            /'_')    |  ___|__  __| (_)/ _|_   _\n     .-^^^-/  /      | |_ / _ \\/ _` | | |_| | | |\n   __/       /       |  _|  __/ (_| | |  _| |_| |\n  \u003c__.|_|-|_|        |_|  \\___|\\__,_|_|_|  \\__, |\n                                           |___/\n\n? Choose the JavaScript runtime to use\n  Deno\n  Bun\n❯ Node.js\n\n? Choose the package manager to use\n❯ npm\n  Yarn\n  pnpm\n\n? Choose the web framework to integrate Fedify with\n  Bare-bones\n  Fresh\n❯ Hono\n  Express\n  Nitro\n\n? Choose the key-value store to use for caching\n❯ In-memory\n  Redis\n  PostgreSQL\n  Deno KV\n\n? Choose the message queue to use for background jobs\n❯ In-process\n  Redis\n  PostgreSQL\n  Deno KV\n----\n\nNOTE: Fedifyはフルスタックフレームワークではなく、​ActivityPubサーバーの実装に特化したフレームワークです。​したがって、​他のウェブフレームワークと一緒に使用することを前提に設計されています。​このチュートリアルでは、​ウェブフレームワークとしてlink:https://hono.dev/[Hono]を採用し、​Fedifyと共に使用します。\n\nしばらくすると、​作業ディレクトリ内に以下のような構造でファイルが生成されるのが確認できます：\n\n* _.vscode/_ — Visual Studio Code関連の設定\n** _extensions.json_ — Visual Studio Code推奨拡張機能\n** _settings.json_ — Visual Studio Code設定\n* _node_modules/_ — 依存パッケージがインストールされるディレクトリ（内容省略）\n* _src/_ — ソースコード\n** _app.tsx_ — ActivityPubと関係ないサーバー\n** _federation.ts_ — ActivityPubサーバー\n** _index.ts_ — エントリーポイント\n** _logging.ts_ — ロギング設定\n* _biome.json_ — フォーマッターおよびリント設定\n* _package.json_ — パッケージメタデータ\n* _tsconfig.json_ — TypeScript設定\n\n想像できると思いますが、​JavaScriptではなくTypeScriptを使用するため、​__.js__ファイルではなく__.ts__および__.tsx__ファイルがあります。\n\n生成されたソースコードは動作するデモです。​まずはこの状態で正常に動作するか確認しましょう：\n\n[source,console]\n$ npm run dev\n\n上記のコマンドを実行すると、​kbd:[Ctrl+C]キーを押すまでサーバーが実行されたままになります：\n\n[listing]\nServer started at http://0.0.0.0:8000\n\nサーバーが実行された状態で、​新しいターミナルタブを開き、​以下のコマンドを実行します：\n\n[source,console]\n$ fedify lookup http://localhost:8000/users/john\n\n上記のコマンドは、​ローカルで起動したActivityPubサーバーの1つのアクター（actor）を照会したものです。​ActivityPubにおいて、​アクターは様々なActivityPubサーバー間でアクセス可能なアカウントだと考えてください。\n\n以下のような結果が出力されれば正常です：\n\n[listing]\n✔ Looking up the object...\nPerson {\n  id: URL \"http://localhost:8000/users/john\",\n  name: \"john\",\n  preferredUsername: \"john\"\n}\n\nこの結果から、​__/users/john__パスに位置するアクターオブジェクトの種類が``Person``であり、​そのIDが__http://localhost:8000/users/john__、​名前が__john__、​ユーザー名も__john__であることがわかります。\n\n[TIP]\n====\n``fedify lookup``はActivityPubオブジェクトを照会するコマンドです。​これはMastodonで該当URIを検索するのと同じ動作をします。​（もちろん、​現在皆さんのサーバーはローカルでのみアクセス可能なため、​まだMastodonで検索しても結果は表示されません）\n\n``fedify lookup``コマンドよりも``curl``を好む場合は、​以下のコマンドでもアクター照会が可能です（``-H``オプションで``Accept``ヘッダーを一緒に送信することに注意してください）：\n\n[source,console]\n$ curl -H\"Accept: application/activity+json\" http://localhost:8000/users/john\n\nただし、​上記のように照会すると、​その結果は人間の目で確認しにくいJSON形式になります。​システムに``jq``コマンドもインストールされている場合は、​``curl``と``jq``を組み合わせて使用することもできます：\n\n[source,console]\n$ curl -H\"Accept: application/activity+json\" http://localhost:8000/users/john | jq .\n====\n\n=== Visual Studio Code\n\nhttps://code.visualstudio.com/[Visual Studio Code]が皆さんのお気に入りのエディタでない可能性もあります。​しかし、​このチュートリアルを進める間はVisual Studio Codeを使用することをお勧めします。​なぜなら、​TypeScriptを使用する必要があり、​Visual Studio Codeは現存する最も便利で優れたTypeScript IDEだからです。​また、​生成されたプロジェクトセットアップにはすでにVisual Studio Codeの設定が整っているため、​フォーマッターやリントなどと格闘する必要もありません。\n\nCAUTION: Visual Studioと混同しないようにしてください。​Visual Studio CodeとVisual Studioはブランドを共有しているだけで、​まったく異なるソフトウェアです。\n\nhttps://code.visualstudio.com/docs/setup/setup-overview[Visual Studio Codeをインストール]した後、​menu:ファイル[フォルダを開く…]メニューをクリックして作業ディレクトリを読み込んでください。\n\n右下に「このリポジトリ 用のおすすめ拡張機能 'Biome' 拡張機能 提供元: biomejs をインストールしますか?」と尋ねるウィンドウが表示された場合は、​btn:[インストール]ボタンをクリックしてその拡張機能をインストールしてください。​この拡張機能をインストールすると、​TypeScriptコードを作成する際にインデントや空白など、​コードスタイルと格闘する必要がなく、​自動的にコードがフォーマットされます。\n\nTIP: 熱心なEmacsまたはVimユーザーの場合、​使い慣れたお気に入りのエディタを使用することを止めはしません。​ただし、​TypeScript LSPの設定は確認しておくことをお勧めします。​TypeScript LSPの設定の有無により、​生産性に大きな差が出るからです。\n\n== 予備知識\n\n=== TypeScript\n\nコードを修正する前に、​簡単にTypeScriptについて触れておきましょう。​すでにTypeScriptに慣れている方は、​この章をスキップしても構いません。\n\nTypeScriptはJavaScriptに静的型チェックを追加したものです。​TypeScriptの文法はJavaScriptの文法とほぼ同じですが、​変数や関数の文法に型を指定できるという大きな違いがあります。​型指定は変数やパラメータの後にコロン（`:`）をつけて表します。\n\n例えば、​次のコードは``foo``変数が文字列（`string`）であることを示しています：\n\n[source,typescript]\nlet foo: string;\n\n上記のように宣言された``foo``変数に文字列以外の型の値を代入しようとすると、​Visual Studio Codeが**実行する前に**赤い下線を引いて型エラーを表示します：\n\n[source,typescript]\n----\nfoo = 123;  // \u003c1\u003e\n----\n\u003c1\u003e ts(2322): 型``number``を型``string``に割り当てることはできません。\n\nコーディング中に赤い下線が表示されたら、​無視せずに対処してください。​無視してプログラムを実行すると、​その部分で実際にエラーが発生する可能性が高いです。\n\nTypeScriptでコーディングをしていて最も頻繁に遭遇する型エラーは、​``null``の可能性があるエラーです。​例えば、​次のコードでは``bar``変数が文字列（`string`）である可能性もあれば``null``である可能性もある（`string | null`）と示されています：\n\n[source,typescript]\nconst bar: string | null = someFunction();\n\nこの変数の内容から最初の文字を取り出そうとして、​次のようなコードを書くとどうなるでしょうか：\n\n[source,typescript]\n----\nconst firstChar = bar.charAt(0);  // \u003c1\u003e\n----\n\u003c1\u003e ts(18047): ``bar``は``null``の可能性があります。\n\n上記のように型エラーが発生します。​``bar``が場合によっては``null``である可能性があり、​その場合に``null.charAt(0)``を呼び出すとエラーが発生する可能性があるため、​コードを修正するよう指摘しています。​このような場合、​以下のように``null``の場合の処理を追加する必要があります：\n\n[source,typescript]\nconst firstChar = bar === null ? \"\" : bar.charAt(0);\n\nこのように、​TypeScriptはコーディング時に気づかなかった場合の数を想起させ、​バグを未然に防ぐのに役立ちます。\n\nまた、​TypeScriptの副次的な利点の一つは、​自動補完が機能することです。​例えば、​``foo.``まで入力すると、​文字列オブジェクトが持つメソッドのリストが表示され、​その中から選択できます。​これにより、​一々ドキュメントを確認しなくても迅速にコーディングが可能になります。\n\nこのチュートリアルを進めながら、​TypeScriptの魅力も一緒に感じていただければと思います。​何より、​FedifyはTypeScriptと一緒に使用したときに最も良い体験が得られるのです。\n\nTIP: TypeScriptをしっかりじっくり学びたい場合は、​公式のlink:https://www.typescriptlang.org/docs/handbook/intro.html[TypeScriptハンドブック]（英語）を読むことをお勧めします。​全部読むのに約30分ほどかかります。\n\n=== JSX\n\nJSXはJavaScriptコード内にXMLまたはHTMLを挿入できるようにするJavaScriptの文法拡張です。​TypeScriptでも使用でき、​その場合はTSXと呼ぶこともあります。​このチュートリアルでは、​すべてのHTMLをJSX文法を通じてJavaScriptコード内に記述します。​JSXにすでに慣れている方は、​この章をスキップして構いません。\n\n例えば、​以下のコードは``\u003cdiv\u003e``要素が最上位にあるHTMLツリーを``html``変数に代入します：\n\n[source,tsx]\nconst html = \u003cdiv\u003e\n  \u003cp id=\"greet\"\u003eこんにちは、​\u003cstrong\u003eJSX\u003c/strong\u003e！\u003c/p\u003e\n\u003c/div\u003e;\n\n中括弧を使用してJavaScript式を挿入することも可能です（以下のコードは、​もちろん``getName()``関数が存在すると仮定しています）：\n\n[source,tsx]\nconst html = \u003cdiv title={\"こんにちは、​\" + getName() + \"！\"}\u003e\n  \u003cp id=\"greet\"\u003eこんにちは、​\u003cstrong\u003e{getName()}\u003c/strong\u003e！\u003c/p\u003e\n\u003c/div\u003e;\n\nJSXの特徴の1つは、​コンポーネント（component）と呼ばれる独自のタグを定義できることです。​コンポーネントは普通のJavaScript関数として定義できます。​例えば、​以下のコードは``\u003cContainer\u003e``コンポーネントを定義して使用する方法を示しています（コンポーネント名は一般的にPascalCaseスタイルに従います）：\n\n[source,tsx]\n----\nimport type { FC } from \"hono/jsx\";\n\nfunction getName() {\n  return \"JSX\";\n}\n\ninterface ContainerProps {\n  name: string;\n}\n\nconst Container: FC\u003cContainerProps\u003e = (props) =\u003e {\n  return \u003cdiv title={\"こんにちは、​\" + props.name + \"！\"}\u003e{props.children}\u003c/div\u003e;\n};\n\nconst html = \u003cContainer name={getName()}\u003e\n  \u003cp id=\"greet\"\u003eこんにちは、​\u003cstrong\u003e{getName()}\u003c/strong\u003e！\u003c/p\u003e\n\u003c/Container\u003e;\n----\n\n上記のコードで``FC``は、​我々が使用するウェブフレームワークであるlink:https://hono.dev/[Hono]が提供するもので、​コンポーネントの型を定義するのに役立ちます。​``FC``はlink:https://www.typescriptlang.org/docs/handbook/2/generics.html[ジェネリック型]（generic type）で、​``FC\u003cContainerProps\u003e``のように山括弧内に入る型が型引数です。​ここでは型引数としてプロップ（props）の形式を指定しています。​プロップとは、​コンポーネントに渡すパラメータのことを指します。​上記のコードでは、​``\u003cContainer\u003e``コンポーネントのプロップ形式として``ContainerProps``インターフェースを宣言して使用しています。\n\n[NOTE]\n====\nジェネリック型の型引数は複数になる場合があり、​カンマで各引数を区切ります。​例えば、​``Foo\u003cA, B\u003e``はジェネリック型``Foo``に型引数``A``と``B``を適用したものです。\n\nまた、​ジェネリック関数というものもあり、​``someFunction\u003cA, B\u003e(foo, bar)``のように表記します。\n\n型引数が1つの場合、​型引数を囲む山括弧がXML/HTMLタグのように見えますが、​JSXの機能とは無関係です。\n\n- `FC\u003cContainerProps\u003e`：ジェネリック型``FC``に型引数``ContainerProps``を適用したもの。\n- `\u003cContainer\u003e`：``\u003cContainer\u003e``という名前のコンポーネントタグを開いたもの。​``\u003c/Container\u003e``で閉じる必要があります。\n====\n\nプロップとして渡されるもののうち、​``children``は特に注目する必要があります。​これはコンポーネントの子要素が``children``プロップとして渡されるためです。​結果として、​上記のコードで``html``変数には``\u003cdiv title=\"こんにちは、​JSX！\"\u003e\u003cp id=\"greet\"\u003eこんにちは、​\u003cstrong\u003eJSX\u003c/strong\u003e！\u003c/p\u003e\u003c/div\u003e``というHTMLツリーが代入されることになります。\n\nTIP: JSXはReactプロジェクトで発明され、​広く使用され始めました。​JSXについて詳しく知りたい場合は、​Reactのドキュメントのlink:https://ja.react.dev/learn/writing-markup-with-jsx[JSXでマークアップを記述する]およびlink:https://ja.react.dev/learn/javascript-in-jsx-with-curly-braces[JSXに波括弧でJavaScriptを含める]セクションを読んでみてください。\n\n== アカウント作成ページ\n\nさて、​本格的な開発に取り掛かりましょう。\n\n最初に作成するのはアカウント作成ページです。​アカウントを作成しないと投稿もできず、​他のアカウントをフォローすることもできませんからね。​まずは見える部分から作り始めましょう。\n\nまず、​__src/views.tsx__ファイルを作成します。​そして、​そのファイル内にJSXで``\u003cLayout\u003e``コンポーネントを定義します：\n\n[source,tsx]\n----\nimport type { FC } from \"hono/jsx\";\n\nexport const Layout: FC = (props) =\u003e (\n  \u003chtml lang=\"en\"\u003e\n    \u003chead\u003e\n      \u003cmeta charset=\"utf-8\" /\u003e\n      \u003cmeta name=\"viewport\" content=\"width=device-width, initial-scale=1\" /\u003e\n      \u003cmeta name=\"color-scheme\" content=\"light dark\" /\u003e\n      \u003ctitle\u003eMicroblog\u003c/title\u003e\n      \u003clink\n        rel=\"stylesheet\"\n        href=\"https://cdn.jsdelivr.net/npm/@picocss/pico@2/css/pico.min.css\"\n      /\u003e\n    \u003c/head\u003e\n    \u003cbody\u003e\n      \u003cmain class=\"container\"\u003e{props.children}\u003c/main\u003e\n    \u003c/body\u003e\n  \u003c/html\u003e\n);\n----\n\nデザインに多くの時間を費やさないために、​link:https://picocss.com/[Pico CSS]というCSSフレームワークを使用することにします。\n\nTIP: 変数やパラメータの型をTypeScriptの型チェッカーが推論できる場合、​上記の``props``のように型表記を省略しても問題ありません。​このように型表記が省略されている場合でも、​Visual Studio Codeで変数名にマウスカーソルを合わせると、​その変数がどの型であるかを確認できます。\n\n次に、​同じファイル内でレイアウトの中に入る``\u003cSetupForm\u003e``コンポーネントを定義します：\n\n[source,tsx]\n----\nexport const SetupForm: FC = () =\u003e (\n  \u003c\u003e\n    \u003ch1\u003eSet up your microblog\u003c/h1\u003e\n    \u003cform method=\"post\" action=\"/setup\"\u003e\n      \u003cfieldset\u003e\n        \u003clabel\u003e\n          Username{\" \"}\n          \u003cinput\n            type=\"text\"\n            name=\"username\"\n            required\n            maxlength={50}\n            pattern=\"^[a-z0-9_\\-]+$\"\n          /\u003e\n        \u003c/label\u003e\n      \u003c/fieldset\u003e\n      \u003cinput type=\"submit\" value=\"Setup\" /\u003e\n    \u003c/form\u003e\n  \u003c/\u003e\n);\n----\n\nJSXでは最上位に1つの要素しか置けませんが、​``\u003cSetupForm\u003e``コンポーネントでは``\u003ch1\u003e``と``\u003cform\u003e``の2つの要素を最上位に置いています。​そのため、​これを1つの要素のようにまとめるために、​空のタグの形の``\u003c\u003e``と``\u003c/\u003e``で囲んでいます。​これをフラグメント（fragment）と呼びます。\n\n定義したコンポーネントを組み合わせて使用する番です。​__src/app.tsx__ファイルで、​先ほど定義した2つのコンポーネントを``import``します：\n\n[source,typescript]\nimport { Layout, SetupForm } from \"./views.tsx\";\n\nそして、​__/setup__ページで先ほど作成したアカウント作成フォームを表示します：\n\n[source,tsx]\napp.get(\"/setup\", (c) =\u003e\n  c.html(\n    \u003cLayout\u003e\n      \u003cSetupForm /\u003e\n    \u003c/Layout\u003e,\n  ),\n);\n\nさて、​それではウェブブラウザで\u003chttp://localhost:8000/setup\u003eページを開いてみましょう。​以下のような画面が表示されれば正常です：\n\n.アカウント作成ページ\nimage::account-creation-page.png[アカウント作成ページ,align=center]\n\nNOTE: JSXを使用するには、​ソースファイルの拡張子が__.jsx__または__.tsx__である必要があります。​この章で編集した2つのファイルの拡張子がどちらも__.tsx__であることに注意してください。\n\n=== データベースのセットアップ\n\nさて、​見える部分を実装したので、​次は動作を実装する番です。​アカウント情報を保存する場所が必要ですが、​link:https://www.sqlite.org/[SQLite]を使用することにしましょう。​SQLiteは小規模なアプリケーションに適したリレーショナルデータベースです。\n\nまずはアカウント情報を格納するテーブルを定義しましょう。​今後、​すべてのテーブル定義は__src/schema.sql__ファイルに記述することにします。​アカウント情報は``users``テーブルに格納します：\n\n[source,sql]\n----\nCREATE TABLE IF NOT EXISTS users (\n  id       INTEGER NOT NULL PRIMARY KEY CHECK (id = 1),\n  username TEXT    NOT NULL UNIQUE      CHECK (trim(lower(username)) = username\n                                               AND username \u003c\u003e ''\n                                               AND length(username) \u003c= 50)\n);\n----\n\n我々が作成するマイクロブログは1つのアカウントしか作成できないので、​主キーである``id``カラムが``1``以外の値を許可しないように制約をかけました。​これにより、​``users``テーブルには2つ以上のレコードを格納できなくなります。​また、​アカウントIDを格納する``username``カラムが空の文字列や長すぎる文字列を許可しないように制約を設けました。\n\nでは、​``users``テーブルを作成するために__src/schema.sql__ファイルを実行する必要があります。​そのためには``sqlite3``コマンドが必要ですが、​link:https://www.sqlite.org/download.html[SQLiteのウェブサイトからダウンロードするか]、​各プラットフォームのパッケージマネージャーでインストールできます。​macOSの場合は、​オペレーティングシステムに組み込まれているので、​別途ダウンロードする必要はありません。​直接ダウンロードする場合は、​オペレーティングシステムに合った__sqlite-tools-*.zip__ファイルをダウンロードして解凍してください。​パッケージマネージャーを使用する場合は、​次のコマンドでインストールすることもできます：\n\n[source,console]\n----\n$ sudo apt install sqlite3  # \u003c1\u003e\n$ sudo dnf install sqlite   # \u003c2\u003e\n\u003e choco install sqlite  # \u003c3\u003e\n\u003e scoop install sqlite  # \u003c4\u003e\n\u003e winget install SQLite.SQLite  # \u003c5\u003e\n----\n\u003c1\u003e DebianおよびUbuntu\n\u003c2\u003e FedoraおよびRHEL\n\u003c3\u003e Chocolatey\n\u003c4\u003e Scoop\n\u003c5\u003e Windows Package Manager\n\nさて、​``sqlite3``コマンドの準備ができたら、​これを使用してデータベースファイルを作成しましょう：\n\n[source,console]\n$ sqlite3 microblog.sqlite3 \u003c src/schema.sql\n\n上記のコマンドを実行すると__microblog.sqlite3__ファイルが作成され、​この中にSQLiteデータが保存されます。\n\n=== アプリからデータベースに接続\n\nこれで、​私たちが作成するアプリからSQLiteデータベースを使用するだけになりました。​Node.jsでSQLiteデータベースを使用するには、​SQLiteドライバーライブラリが必要です。​ここではlink:https://github.com/WiseLibs/better-sqlite3[better-sqlite3]パッケージを使用することにします。​パッケージは``npm``コマンドで簡単にインストールできます：\n\n[source,console]\n$ npm add better-sqlite3\n$ npm add --save-dev @types/better-sqlite3\n\n[TIP]\n====\nhttps://www.npmjs.com/package/@types/better-sqlite3[@types/better-sqlite3]パッケージは、​TypeScript用にbetter-sqlite3パッケージのAPIに関する型情報を含んでいます。​このパッケージをインストールすることで、​Visual Studio Codeで編集する際に自動補完や型チェックが可能になります。\n\nこのように、​@types/スコープ内にあるパッケージをlink:https://github.com/DefinitelyTyped/DefinitelyTyped[Definitely Typed]パッケージと呼びます。​あるライブラリがTypeScriptで書かれていない場合、​コミュニティが型情報を追加して作成したパッケージです。\n====\n\nパッケージをインストールしたので、​このパッケージを使用してデータベースに接続するコードを書きましょう。​__src/db.ts__という新しいファイルを作成し、​以下のようにコーディングします：\n\n[source,typescript]\n----\nimport Database from \"better-sqlite3\";\n\nconst db = new Database(\"microblog.sqlite3\");\ndb.pragma(\"journal_mode = WAL\");\ndb.pragma(\"foreign_keys = ON\");\n\nexport default db;\n----\n\n[TIP]\n====\n参考までに、​``db.pragma()``関数を通じて設定した内容は以下のような効果があります：\n\n- https://www.sqlite.org/wal.html[`journal_mode = WAL`]：SQLiteでアトミックなコミットとロールバックを実装する方法としてlink:https://ja.wikipedia.org/wiki/%E3%83%AD%E3%82%B0%E5%85%88%E8%A1%8C%E6%9B%B8%E3%81%8D%E8%BE%BC%E3%81%BF[ログ先行書き込み]モードを採用します。​このモードは、​デフォルトのlink:https://www.sqlite.org/lockingv3.html#rollback[ロールバックジャーナル]モードに比べて、​ほとんどの場合でパフォーマンスが優れています。\n- https://www.sqlite.org/foreignkeys.html[`foreign_keys = ON`]：SQLiteではデフォルトで外部キー制約をチェックしません。​この設定をオンにすると外部キー制約をチェックするようになり、​データの整合性を保つのに役立ちます。\n====\n\nそして、​``users``テーブルに保存されるレコードをJavaScriptで表現する型を宣言しましょう。​__src/schema.ts__ファイルを作成し、​以下のように``User``型を定義します：\n\n[source,typescript]\nexport interface User {\n  id: number;\n  username: string;\n}\n\n=== レコードの挿入\n\nデータベースに接続したので、​レコードを挿入する番です。\n\nまず__src/app.tsx__ファイルを開き、​レコード挿入に使用する``db``オブジェクトと``User``型を``import``します：\n\n[source,typescript]\nimport db from \"./db.ts\";\nimport type { User } from \"./schema.ts\";\n\n``POST /setup``ハンドラを実装します：\n\n[source,typescript]\n----\napp.post(\"/setup\", async (c) =\u003e {\n  // アカウントが既に存在するか確認\n  const user = db.prepare\u003cunknown[], User\u003e(\"SELECT * FROM users LIMIT 1\").get();\n  if (user != null) return c.redirect(\"/\");\n\n  const form = await c.req.formData();\n  const username = form.get(\"username\");\n  if (typeof username !== \"string\" || !username.match(/^[a-z0-9_-]{1,50}$/)) {\n    return c.redirect(\"/setup\");\n  }\n  db.prepare(\"INSERT INTO users (username) VALUES (?)\").run(username);\n  return c.redirect(\"/\");\n});\n----\n\n先ほど作成した``GET /setup``ハンドラにもアカウントが既に存在するかチェックするコードを追加します：\n\n[source,tsx,highlight=2..4]\n----\napp.get(\"/setup\", (c) =\u003e {\n  // アカウントが既に存在するか確認\n  const user = db.prepare\u003cunknown[], User\u003e(\"SELECT * FROM users LIMIT 1\").get();\n  if (user != null) return c.redirect(\"/\");\n\n  return c.html(\n    \u003cLayout\u003e\n      \u003cSetupForm /\u003e\n    \u003c/Layout\u003e,\n  );\n});\n----\n\n=== テスト\n\nこれでアカウント作成機能がひととおり実装されたので、​実際に使ってみましょう。​ウェブブラウザで\u003chttp://localhost:8000/setup\u003eページを開いてアカウントを作成してください。​このチュートリアルでは、​これ以降、​ユーザー名として__johndoe__を使用したと仮定します。​作成できたら、​SQLiteデータベースにレコードが正しく挿入されたか確認もしてみましょう：\n\n[source,console]\n$ echo \"SELECT * FROM users;\" | sqlite3 -table microblog.sqlite3\n\nレコードが正しく挿入されていれば、​以下のような出力が表示されるはずです（もちろん、​``johndoe``は皆さんが入力したユーザー名によって異なります）：\n\n[cols=\"1,1\"]\n|===\n| `id` | `username`\n\n| `1`\n| `johndoe`\n|===\n\n== プロフィールページ\n\nこれでアカウントが作成されたので、​アカウント情報を表示するプロフィールページを実装しましょう。​表示する情報はほとんどありませんが。\n\n今回も見える部分から作業を始めましょう。​__src/views.tsx__ファイルに``\u003cProfile\u003e``コンポーネントを定義します：\n\n[source,tsx]\n----\nexport interface ProfileProps {\n  name: string;\n  handle: string;\n}\n\nexport const Profile: FC\u003cProfileProps\u003e = ({ name, handle }) =\u003e (\n  \u003c\u003e\n    \u003chgroup\u003e\n      \u003ch1\u003e{name}\u003c/h1\u003e\n      \u003cp style=\"user-select: all;\"\u003e{handle}\u003c/p\u003e\n    \u003c/hgroup\u003e\n  \u003c/\u003e\n);\n----\n\nそして__src/app.tsx__ファイルで定義したコンポーネントを``import``します：\n\n[source,typescript]\nimport { Layout, Profile, SetupForm } from \"./views.tsx\";\n\nそして``\u003cProfile\u003e``コンポーネントを表示する``GET /users/{username}``ハンドラを追加します：\n\n[source,tsx]\n----\napp.get(\"/users/:username\", async (c) =\u003e {\n  const user = db\n    .prepare\u003cunknown[], User\u003e(\"SELECT * FROM users WHERE username = ?\")\n    .get(c.req.param(\"username\"));\n  if (user == null) return c.notFound();\n\n  const url = new URL(c.req.url);\n  const handle = `@${user.username}@${url.host}`;\n  return c.html(\n    \u003cLayout\u003e\n      \u003cProfile name={user.username} handle={handle} /\u003e\n    \u003c/Layout\u003e,\n  );\n});\n----\n\nここまでできたらテストをしてみましょう。​ウェブブラウザで\u003chttp://localhost:8000/users/johndoe\u003eページを開いてみてください（アカウント作成時にユーザー名を``johndoe``にした場合。​そうでない場合はURLを変更する必要があります）。​以下のような画面が表示されるはずです：\n\n.プロフィールページ\nimage::profile-page.png[プロフィールページ,align=center]\n\n[TIP]\n====\nフェディバースハンドル（fediverse handle）、​略してハンドルとは、​フェディバース内でアカウントを指す一意なアドレスのようなものです。​例えば``+@hongminhee@hollo.social+``のような形をしています。​メールアドレスに似た形をしていますが、​実際の構成もメールアドレスに似ています。​最初に``@``が来て、​その後に名前、​そして再び``@``が来た後、​最後にアカウントが属するサーバーのドメイン名が来ます。​時々、​最初の``@``が省略されることもあります。\n\n技術的には、​ハンドルはlink:https://datatracker.ietf.org/doc/html/rfc7033[WebFinger]とlink:https://datatracker.ietf.org/doc/html/rfc7565[`acct:` URI形式]という2つの標準で実装されています。​Fedifyがこれを実装しているため、​このチュートリアルを進める間は実装の詳細を知らなくても大丈夫です。\n====\n\n== アクターの実装\n\nActivityPubは、​その名前が示すように、​アクティビティ（activity）を送受信するプロトコルです。​投稿、​投稿の編集、​投稿の削除、​投稿へのいいね、​コメントの追加、​プロフィールの編集…ソーシャルメディアで起こるすべての出来事をアクティビティとして表現します。\n\nそして、​すべてのアクティビティはアクター（actor）からアクターへ送信されます。​例えば、​山田太郎が投稿を作成すると、​「投稿作成」（`Create(Note)`）アクティビティが山田太郎から山田太郎のフォロワーたちに送信されます。​その投稿に佐藤花子がいいねをすると、​「いいね」（`Like`）アクティビティが佐藤花子から山田太郎に送信されます。\n\nしたがって、​ActivityPubを実装する最初のステップはアクターを実装することです。\n\n``fedify init``コマンドで生成されたデモアプリには既にとてもシンプルなアクターが実装されていますが、​MastodonやMisskeyなどの実際のソフトウェアと通信するためには、​アクターをもう少しきちんと実装する必要があります。\n\nまずは、​現在の実装を一度見てみましょう。​__src/federation.ts__ファイルを開いてみましょう：\n\n[source,typescript,highlight=12..18]\n----\nimport { Person, createFederation } from \"@fedify/fedify\";\nimport { InProcessMessageQueue, MemoryKvStore } from \"@fedify/fedify\";\nimport { getLogger } from \"@logtape/logtape\";\n\nconst logger = getLogger(\"microblog\");\n\nconst federation = createFederation({\n  kv: new MemoryKvStore(),\n  queue: new InProcessMessageQueue(),\n});\n\nfederation.setActorDispatcher(\"/users/{identifier}\", async (ctx, identifier) =\u003e {\n  return new Person({\n    id: ctx.getActorUri(identifier),\n    preferredUsername: identifier,\n    name: identifier,\n  });\n});\n\nexport default federation;\n----\n\n注目すべき部分は``setActorDispatcher()``メソッドです。​このメソッドは、​他のActivityPubソフトウェアが我々が作成したサーバーのアクターを照会する際に使用するURLとその動作を定義します。​例えば、​先ほど我々が行ったように__/users/johndoe__を照会すると、​コールバック関数の``identifier``パラメータに``\"johndoe\"``という文字列値が入ってきます。​そして、​コールバック関数は``Person``クラスのインスタンスを返して、​照会されたアクターの情報を伝達します。\n\n``ctx``パラメータには``Context``オブジェクトが渡されますが、​これはActivityPubプロトコルに関連する様々な機能を含むオブジェクトです。​例えば、​上記のコードで使用されている``getActorUri()``メソッドは、​パラメータとして渡された``identifier``を含むアクターの一意なURIを返します。​このURIは``Person``オブジェクトの一意な識別子として使用されています。\n\n実装コードを見ればわかるように、​現在は__/users/__パスの後にどのようなハンドルが来ても、​呼び出されたままのアクター情報を**作り出して**返しています。​しかし、​我々が望むのは実際に登録されているアカウントについてのみ照会できるようにすることです。​この部分をデータベースに存在するアカウントについてのみ返すように修正しましょう。\n\n=== テーブルの作成\n\n``actors``テーブルを作成する必要があります。​このテーブルは、​現在のインスタンスサーバーのアカウントのみを含む``users``テーブルとは異なり、​連合されるサーバーに属するリモートアクターも含みます。​テーブルは次のようになります。​__src/schema.sql__ファイルに次のSQLを追加してください：\n\n[source,sql]\n----\nCREATE TABLE IF NOT EXISTS actors (\n  id               INTEGER NOT NULL PRIMARY KEY,\n  user_id          INTEGER          REFERENCES users (id),                       -- \u003c1\u003e\n  uri              TEXT    NOT NULL UNIQUE CHECK (uri \u003c\u003e ''),                    -- \u003c2\u003e\n  handle           TEXT    NOT NULL UNIQUE CHECK (handle \u003c\u003e ''),                 -- \u003c3\u003e\n  name             TEXT,                                                         -- \u003c4\u003e\n  inbox_url        TEXT    NOT NULL UNIQUE CHECK (inbox_url LIKE 'https://%'     -- \u003c5\u003e\n                                                  OR inbox_url LIKE 'http://%'),\n  shared_inbox_url TEXT                    CHECK (shared_inbox_url               -- \u003c6\u003e\n                                                  LIKE 'https://%'\n                                                  OR shared_inbox_url\n                                                  LIKE 'http://%'),\n  url              TEXT                    CHECK (url LIKE 'https://%'           -- \u003c7\u003e\n                                                  OR url LIKE 'http://%'),\n  created          TEXT    NOT NULL DEFAULT (CURRENT_TIMESTAMP)                  -- \u003c8\u003e\n                                           CHECK (created \u003c\u003e '')\n);\n----\n\u003c1\u003e ``user_id``カラムは``users``カラムと連携するための外部キーです。​該当レコードがリモートアクターを表す場合は``NULL``が入りますが、​現在のインスタンスサーバーのアカウントの場合は該当アカウントの``users.id``値が入ります。\n\u003c2\u003e ``uri``カラムはアクターIDと呼ばれるアクターの一意なURIを含みます。​アクターを含むすべてのActivityPubオブジェクトはURI形式の一意なIDを持ちます。​したがって、​空にすることはできず、​重複もできません。\n\u003c3\u003e ``handle``カラムは``+@johndoe@example.com+``形式のフェディバースハンドルを含みます。​同様に、​空にすることはできず、​重複もできません。\n\u003c4\u003e ``name``カラムはUIに表示される名前を含みます。​通常はフルネームやニックネームが入ります。​ただし、​ActivityPub仕様に従い、​このカラムは空になる可能性があります。\n\u003c5\u003e ``inbox_url``カラムは該当アクターのインボックス（inbox）URLを含みます。​インボックスが何であるかについては後で詳しく説明しますが、​現時点ではアクターに必須で存在しなければならないということだけ覚えておいてください。​このカラムも空にすることはできず、​重複もできません。\n\u003c6\u003e ``shared_inbox_url``カラムは該当アクターの共有インボックス（shared inbox）URLを含みます。​これについても後で詳しく説明します。​必須ではないため、​空になる可能性があり、​カラム名の通り他のアクターと同じ共有インボックスURLを共有することもできます。\n\u003c7\u003e ``url``カラムは該当アクターのプロフィールURLを含みます。​プロフィールURLとは、​ウェブブラウザで開いて見ることができるプロフィールページのURLを意味します。​アクターのIDとプロフィールURLが同じ場合もありますが、​サービスによって異なる場合もあるため、​その場合にこのカラムにプロフィールURLを含めます。​空になる可能性があります。\n\u003c8\u003e ``created``カラムはレコードが作成された時点を記録します。​空にすることはできず、​デフォルトで挿入時点の時刻が記録されます。\n\nさて、​これで__src/schema.sql__ファイルを__microblog.sqlite3__データベースファイルに適用しましょう：\n\n[source,console]\n$ sqlite3 microblog.sqlite3 \u003c src/schema.sql\n\nTIP: 先ほど``users``テーブルを定義する際に``CREATE TABLE IF NOT EXISTS``文を使用したため、​何度実行しても問題ありません。\n\nそして、​``actors``テーブルに保存されるレコードをJavaScriptで表現する型も__src/schema.ts__に定義します：\n\n[source,typescript]\nexport interface Actor {\n  id: number;\n  user_id: number | null;\n  uri: string;\n  handle: string;\n  name: string | null;\n  inbox_url: string;\n  shared_inbox_url: string | null;\n  url: string | null;\n  created: string;\n}\n\n=== アクターレコード\n\n現在``users``テーブルにレコードが1つありますが、​これと対応するレコードが``actors``テーブルにはありません。​アカウントを作成する際に``actors``テーブルにレコードを追加しなかったためです。​アカウント作成コードを修正して``users``と``actors``の両方にレコードを追加するようにする必要があります。\n\nまず__src/views.tsx__にある``SetupForm``で、​ユーザー名と一緒に``actors.name``カラムに入れる名前も入力を受け付けるようにしましょう：\n\n[source,tsx,highlight=16..18]\nexport const SetupForm: FC = () =\u003e (\n  \u003c\u003e\n    \u003ch1\u003eSet up your microblog\u003c/h1\u003e\n    \u003cform method=\"post\" action=\"/setup\"\u003e\n      \u003cfieldset\u003e\n        \u003clabel\u003e\n          Username{\" \"}\n          \u003cinput\n            type=\"text\"\n            name=\"username\"\n            required\n            maxlength={50}\n            pattern=\"^[a-z0-9_\\-]+$\"\n          /\u003e\n        \u003c/label\u003e\n        \u003clabel\u003e\n          Name \u003cinput type=\"text\" name=\"name\" required /\u003e\n        \u003c/label\u003e\n      \u003c/fieldset\u003e\n      \u003cinput type=\"submit\" value=\"Setup\" /\u003e\n    \u003c/form\u003e\n  \u003c/\u003e\n);\n\n先ほど定義した``Actor``型を__src/app.tsx__で``import``します：\n\n[source,typescript]\nimport type { Actor, User } from \"./schema.ts\";\n\nこれで入力された名前をはじめ、​必要な情報を``actors``テーブルのレコードとして作成するコードを``POST /setup``ハンドラに追加します：\n\n[source,typescript,highlight=7,19..24,26,30..44]\n----\napp.post(\"/setup\", async (c) =\u003e {\n  // アカウントが既に存在するか確認\n  const user = db\n    .prepare\u003cunknown[], User\u003e(\n      `\n      SELECT * FROM users\n      JOIN actors ON (users.id = actors.user_id)\n      LIMIT 1\n      `,\n    )\n    .get();\n  if (user != null) return c.redirect(\"/\");\n\n  const form = await c.req.formData();\n  const username = form.get(\"username\");\n  if (typeof username !== \"string\" || !username.match(/^[a-z0-9_-]{1,50}$/)) {\n    return c.redirect(\"/setup\");\n  }\n  const name = form.get(\"name\");\n  if (typeof name !== \"string\" || name.trim() === \"\") {\n    return c.redirect(\"/setup\");\n  }\n  const url = new URL(c.req.url);\n  const handle = `@${username}@${url.host}`;\n  const ctx = fedi.createContext(c.req.raw, undefined);\n  db.transaction(() =\u003e {\n    db.prepare(\"INSERT OR REPLACE INTO users (id, username) VALUES (1, ?)\").run(\n      username,\n    );\n    db.prepare(\n      `\n      INSERT OR REPLACE INTO actors\n        (user_id, uri, handle, name, inbox_url, shared_inbox_url, url)\n      VALUES (1, ?, ?, ?, ?, ?, ?)\n    `,\n    ).run(\n      ctx.getActorUri(username).href,\n      handle,\n      name,\n      ctx.getInboxUri(username).href,\n      ctx.getInboxUri().href,\n      ctx.getActorUri(username).href,\n    );\n  })();\n  return c.redirect(\"/\");\n});\n----\n\nアカウントが既に存在するかチェックする際、​``users``テーブルにレコードがない場合だけでなく、​対応するレコードが``actors``テーブルにない場合もまだアカウントが存在しないと判断するように修正しました。​同じ条件を``GET /setup``ハンドラおよび``GET /users/{username}``ハンドラにも適用します：\n\n[source,tsx,highlight=7]\n----\napp.get(\"/setup\", (c) =\u003e {\n  // アカウントが既に存在するか確認\n  const user = db\n    .prepare\u003cunknown[], User\u003e(\n      `\n      SELECT * FROM users\n      JOIN actors ON (users.id = actors.user_id)\n      LIMIT 1\n      `,\n    )\n    .get();\n  if (user != null) return c.redirect(\"/\");\n\n  return c.html(\n    \u003cLayout\u003e\n      \u003cSetupForm /\u003e\n    \u003c/Layout\u003e,\n  );\n});\n----\n\n[source,tsx,highlight=6]\n----\napp.get(\"/users/:username\", async (c) =\u003e {\n  const user = db\n    .prepare\u003cunknown[], User \u0026 Actor\u003e(\n      `\n      SELECT * FROM users\n      JOIN actors ON (users.id = actors.user_id)\n      WHERE username = ?\n      `,\n    )\n    .get(c.req.param(\"username\"));\n  if (user == null) return c.notFound();\n\n  const url = new URL(c.req.url);\n  const handle = `@${user.username}@${url.host}`;\n  return c.html(\n    \u003cLayout\u003e\n      \u003cProfile name={user.name ?? user.username} handle={handle} /\u003e\n    \u003c/Layout\u003e,\n  );\n});\n----\n\nTIP: TypeScriptでは``A \u0026 B``は``A``型と同時に``B``型であるオブジェクトを意味します。​例えば、​``{ a: number } \u0026 { b: string }``型があるとすると、​``{ a: 123 }``や``{ b: \"foo\" }``はこの型を満たしませんが、​``{ a: 123, b: \"foo\" }``はこの型を満たします。\n\n最後に、​__src/federation.ts__ファイルを開き、​アクターディスパッチャーの下に次のコードを追加します：\n\n[source,typescript]\nfederation.setInboxListeners(\"/users/{identifier}/inbox\", \"/inbox\");\n\n``setInboxListeners()``メソッドは今のところ気にしないでください。​これもまたインボックスについて説明する際に一緒に扱うことにします。​ただ、​アカウント作成コードで使用した``getInboxUri()``メソッドが正しく動作するためには上記のコードが必要だという点だけ指摘しておきます。\n\nコードをすべて修正したら、​ブラウザで\u003chttp://localhost:8000/setup\u003eページを開いて再度アカウントを作成します：\n\n.アカウント作成ページ\nimage::account-creation-page-2.png[アカウント作成ページ,align=center]\n\n=== アクターディスパッチャー\n\n``actors``テーブルを作成してレコードも追加したので、​再び__src/federation.ts__ファイルを修正しましょう。​まず``db``オブジェクトと``Endpoints``および``Actor``を``import``します：\n\n[source,typescript]\nimport { Endpoints, Person, createFederation } from \"@fedify/fedify\";\nimport db from \"./db.ts\";\nimport type { Actor, User } from \"./schema.ts\";\n\n必要なものを``import``したので``setActorDispatcher()``メソッドを修正しましょう：\n\n[source,typescript,highlight=2..11,16..21]\n----\nfederation.setActorDispatcher(\"/users/{identifier}\", async (ctx, identifier) =\u003e {\n  const user = db\n    .prepare\u003cunknown[], User \u0026 Actor\u003e(\n      `\n      SELECT * FROM users\n      JOIN actors ON (users.id = actors.user_id)\n      WHERE users.username = ?\n      `,\n    )\n    .get(identifier);\n  if (user == null) return null;\n\n  return new Person({\n    id: ctx.getActorUri(identifier),\n    preferredUsername: identifier,\n    name: user.name,\n    inbox: ctx.getInboxUri(identifier),\n    endpoints: new Endpoints({\n      sharedInbox: ctx.getInboxUri(),\n    }),\n    url: ctx.getActorUri(identifier),\n  });\n});\n----\n\n変更されたコードでは、​データベースの``users``テーブルを照会して現在のサーバーにあるアカウントでない場合は``null``を返すようになりました。​つまり、​``GET /users/johndoe``（アカウント作成時にユーザー名を``johndoe``にしたと仮定した場合）リクエストに対しては正しい``Person``オブジェクトを``200 OK``とともに応答し、​それ以外のリクエストに対しては``404 Not Found``を応答することになります。\n\n``Person``オブジェクトを生成する部分もどのように変わったか見てみましょう。​まず``name``属性が追加されました。​このプロパティは``actors.name``カラムの値を使用します。​``inbox``と``endpoints``属性はインボックスについて説明するときに一緒に扱うことにします。​``url``属性はこのアカウントのプロフィールURLを含みますが、​このチュートリアルではアクターIDとアクターのプロフィールURLを一致させることにします。\n\n[TIP]\n====\n目のいい方々は気づいたかもしれませんが、​HonoとFedify両方で``GET /users/{identifier}``に対するハンドラを重複して定義しています。​では、​実際にそのリクエストを送信すると、​どちらが応答することになるでしょうか？答えは、​リクエストの``Accept``ヘッダーによって異なります。​``Accept: text/html``ヘッダーと一緒にリクエストを送信すると、​Hono側のリクエストハンドラが応答します。​``Accept: application/activity+json``ヘッダーと一緒にリクエストを送信すると、​Fedify側のリクエストハンドラが応答します。\n\nこのようにリクエストの``Accept``ヘッダーに応じて異なる応答を返す方式をHTTPのlink:https://developer.mozilla.org/ja/docs/Web/HTTP/Content_negotiation[コンテンツネゴシエーション]（content negotiation）と呼び、​Fedify自体がコンテンツネゴシエーションを実装しています。​より具体的には、​すべてのリクエストは一度Fedifyを通過し、​ActivityPubに関連するリクエストでない場合は連携されたフレームワーク、​このチュートリアルではHonoにリクエストを渡すようになっています。\n====\n\nTIP: FedifyではすべてのURIおよびURLをlink:https://developer.mozilla.org/ja/docs/Web/API/URL[`URL`]インスタンスで表現します。\n\n=== テスト\n\nそれでは、​アクターディスパッチャーをテストしてみましょう。\n\nサーバーが起動している状態で、​新しいターミナルタブを開いて以下のコマンドを入力します：\n\n[source,console]\n$ fedify lookup http://localhost:8000/users/alice\n\n``alice``というアカウントが存在しないため、​先ほどとは異なり、​今度は次のようなエラーが発生するはずです：\n\n[listing]\n✔ Looking up the object...\nFailed to fetch the object.\nIt may be a private object.  Try with -a/--authorized-fetch.\n\nでは``johndoe``アカウントも照会してみましょう：\n\n[source,console]\nfedify lookup http://localhost:8000/users/johndoe\n\n今度は結果がきちんと出力されます：\n\n[listing]\n✔ Looking up the object...\nPerson {\n  id: URL \"http://localhost:8000/users/johndoe\",\n  name: \"John Doe\",\n  url: URL \"http://localhost:8000/users/johndoe\",\n  preferredUsername: \"johndoe\",\n  inbox: URL \"http://localhost:8000/users/johndoe/inbox\",\n  endpoints: Endpoints { sharedInbox: URL \"http://localhost:8000/inbox\" }\n}\n\n== 暗号鍵ペア\n\n次に実装するのは、​署名のためのアクターの暗号鍵です。​ActivityPubではアクターがアクティビティを作成して送信しますが、​このときアクティビティを本当にそのアクターが作成したことを証明するためにlink:https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E7%BD%B2%E5%90%8D[デジタル署名]を行います。​そのために、​アクターはペアになった自身だけの秘密鍵（private key）と公開鍵（public key）のペアを作成して持っており、​その公開鍵を他のアクターも見られるように公開します。​アクターはアクティビティを受信する際に、​送信者の公開鍵とアクティビティの署名を検証して、​そのアクティビティが本当に送信者が生成したものかどうかを確認します。​署名と署名の検証はFedifyが自動的に行いますが、​鍵ペアを生成して保存するのは直接実装する必要があります。\n\nCAUTION: 秘密鍵は、​その名前が示すように署名を行う主体以外はアクセスできないようにする必要があります。​一方、​公開鍵はその用途自体が公開することなので、​誰でもアクセスしても問題ありません。\n\n=== テーブルの作成\n\n秘密鍵と公開鍵のペアを保存する``keys``テーブルを__src/schema.sql__に定義します：\n\n[source,sql]\nCREATE TABLE IF NOT EXISTS keys (\n  user_id     INTEGER NOT NULL REFERENCES users (id),\n  type        TEXT    NOT NULL CHECK (type IN ('RSASSA-PKCS1-v1_5', 'Ed25519')),\n  private_key TEXT    NOT NULL CHECK (private_key \u003c\u003e ''),\n  public_key  TEXT    NOT NULL CHECK (public_key \u003c\u003e ''),\n  created     TEXT    NOT NULL DEFAULT (CURRENT_TIMESTAMP) CHECK (created \u003c\u003e ''),\n  PRIMARY KEY (user_id, type)\n);\n\nテーブルをよく見ると、​``type``カラムには2種類の値のみが許可されていることがわかります。​一つはlink:https://www.rfc-editor.org/rfc/rfc2313[RSA-PKCS#1-v1.5]形式で、​もう一つはlink:https://ed25519.cr.yp.to/[Ed25519]形式です。​（それぞれが何を意味するかは、​このチュートリアルでは重要ではありません）主キーが``(user_id, type)``にかかっているので、​1ユーザーに対して最大二つの鍵ペアが存在できます。\n\nTIP: このチュートリアルで詳しく説明することはできませんが、​2024年9月現在、​ActivityPubネットワークはRSA-PKCS#1-v1.5形式からEd25519形式に移行中であると知っておくと良いでしょう。​あるソフトウェアはRSA-PKCS#1-v1.5形式のみを受け入れ、​あるソフトウェアはEd25519形式を受け入れます。​したがって、​両方と通信するためには、​二つの鍵ペアが両方とも必要になるのです。\n\n``private_key``および``public_key``カラムは文字列を受け取れるようになっていますが、​ここにはJSONデータを入れる予定です。​秘密鍵と公開鍵をJSONでエンコードする方法については、​後で順を追って説明します。\n\nでは``keys``テーブルを作成しましょう：\n\n[source,console]\n$ sqlite3 microblog.sqlite3 \u003c src/schema.sql\n\n``keys``テーブルに保存されるレコードをJavaScriptで表現する``Key``型も__src/schema.ts__ファイルに定義します：\n\n[source,typescript]\nexport interface Key {\n  user_id: number;\n  type: \"RSASSA-PKCS1-v1_5\" | \"Ed25519\";\n  private_key: string;\n  public_key: string;\n  created: string;\n}\n\n=== 鍵ペアディスパッチャー\n\nこれで鍵ペアを生成して読み込むコードを書く必要があります。\n\n__src/federation.ts__ファイルを開き、​Fedifyが提供する``exportJwk()``、​``generateCryptoKeyPair()``、​``importJwk()``関数と先ほど定義した``Key``型を``import``しましょう：\n\n[source,typescript,highlight=5..7,9]\n----\nimport {\n  Endpoints,\n  Person,\n  createFederation,\n  exportJwk,\n  generateCryptoKeyPair,\n  importJwk,\n} from \"@fedify/fedify\";\nimport type { Actor, Key, User } from \"./schema.ts\";\n----\n\nそしてアクターディスパッチャー部分を次のように修正します：\n\n[source,typescript]\n----\nfederation\n  .setActorDispatcher(\"/users/{identifier}\", async (ctx, identifier) =\u003e {\n    const user = db\n      .prepare\u003cunknown[], User \u0026 Actor\u003e(\n        `\n        SELECT * FROM users\n        JOIN actors ON (users.id = actors.user_id)\n        WHERE users.username = ?\n        `,\n      )\n      .get(identifier);\n    if (user == null) return null;\n\n    const keys = await ctx.getActorKeyPairs(identifier);\n    return new Person({\n      id: ctx.getActorUri(identifier),\n      preferredUsername: identifier,\n      name: user.name,\n      inbox: ctx.getInboxUri(identifier),\n      endpoints: new Endpoints({\n        sharedInbox: ctx.getInboxUri(),\n      }),\n      url: ctx.getActorUri(identifier),\n      publicKey: keys[0].cryptographicKey,\n      assertionMethods: keys.map((k) =\u003e k.multikey),\n    });\n  })\n  .setKeyPairsDispatcher(async (ctx, identifier) =\u003e {\n    const user = db\n      .prepare\u003cunknown[], User\u003e(\"SELECT * FROM users WHERE username = ?\")\n      .get(identifier);\n    if (user == null) return [];\n    const rows = db\n      .prepare\u003cunknown[], Key\u003e(\"SELECT * FROM keys WHERE keys.user_id = ?\")\n      .all(user.id);\n    const keys = Object.fromEntries(\n      rows.map((row) =\u003e [row.type, row]),\n    ) as Record\u003cKey[\"type\"], Key\u003e;\n    const pairs: CryptoKeyPair[] = [];\n    // ユーザーがサポートする2つの鍵形式（RSASSA-PKCS1-v1_5およびEd25519）それぞれについて\n    // 鍵ペアを保有しているか確認し、​なければ生成後データベースに保存：\n    for (const keyType of [\"RSASSA-PKCS1-v1_5\", \"Ed25519\"] as const) {\n      if (keys[keyType] == null) {\n        logger.debug(\n          \"ユーザー{identifier}は{keyType}鍵を持っていません。​作成します...\",\n          { identifier, keyType },\n        );\n        const { privateKey, publicKey } = await generateCryptoKeyPair(keyType);\n        db.prepare(\n          `\n          INSERT INTO keys (user_id, type, private_key, public_key)\n          VALUES (?, ?, ?, ?)\n          `,\n        ).run(\n          user.id,\n          keyType,\n          JSON.stringify(await exportJwk(privateKey)),\n          JSON.stringify(await exportJwk(publicKey)),\n        );\n        pairs.push({ privateKey, publicKey });\n      } else {\n        pairs.push({\n          privateKey: await importJwk(\n            JSON.parse(keys[keyType].private_key),\n            \"private\",\n          ),\n          publicKey: await importJwk(\n            JSON.parse(keys[keyType].public_key),\n            \"public\",\n          ),\n        });\n      }\n    }\n    return pairs;\n  });\n----\n\nまず最初に注目すべきは、​``setActorDispatcher()``メソッドに連続して呼び出されている``setKeyPairsDispatcher()``メソッドです。​このメソッドは、​コールバック関数から返された鍵ペアをアカウントに紐付ける役割を果たします。​このように鍵ペアを紐付けることで、​Fedifyがアクティビティを送信する際に自動的に登録された秘密鍵でデジタル署名を追加します。\n\n``generateCryptoKeyPair()``関数は新しい秘密鍵と公開鍵のペアを生成し、​``CryptoKeyPair``オブジェクトとして返します。​参考までに、​``CryptoKeyPair``型は``{ privateKey: CryptoKey; publicKey: CryptoKey; }``形式です。\n\n``exportJwk()``関数は``CryptoKey``オブジェクトをJWK形式で表現したオブジェクトを返します。​JWK形式が何かを知る必要はありません。​単に暗号鍵をJSONで表現する標準的な形式だと理解すれば十分です。​``CryptoKey``は暗号鍵をJavaScriptオブジェクトとして表現するためのウェブ標準の型です。\n\n``importJwk()``関数はJWK形式で表現された鍵を``CryptoKey``オブジェクトに変換します。​``exportJwk()``関数の逆だと理解すれば良いでしょう。\n\nさて、​では再び``setActorDispatcher()``メソッドに目を向けましょう。​``getActorKeyPairs()``というメソッドが使われていますが、​このメソッドは名前の通りアクターの鍵ペアを返します。​アクターの鍵ペアは、​直前に見た``setKeyPairsDispatcher()``メソッドで読み込まれたまさにその鍵ペアです。​我々はRSA-PKCS#1-v1.5とEd25519形式の2つの鍵ペアを読み込んだので、​``getActorKeyPairs()``メソッドは2つの鍵ペアの配列を返します。​配列の各要素は鍵ペアを様々な形式で表現したオブジェクトですが、​次のような形をしています：\n\n[source,typescript]\n----\ninterface ActorKeyPair {\n  privateKey: CryptoKey;              // \u003c1\u003e\n  publicKey: CryptoKey;               // \u003c2\u003e\n  keyId: URL;                         // \u003c3\u003e\n  cryptographicKey: CryptographicKey; // \u003c4\u003e\n  multikey: Multikey;                 // \u003c5\u003e\n}\n----\n\u003c1\u003e 秘密鍵\n\u003c2\u003e 公開鍵\n\u003c3\u003e 鍵の一意な識別URI\n\u003c4\u003e 公開鍵の別の形式\n\u003c5\u003e 公開鍵のさらに別の形式\n\n``CryptoKey``と``CryptographicKey``と``Multikey``がそれぞれどう違うのか、​なぜこのように複数の形式が必要なのかは、​ここで説明するには複雑すぎます。​ただ、​現時点では``Person``オブジェクトを初期化する際に``publicKey``属性は``CryptographicKey``形式を受け取り、​``assertionMethods``属性は``Multikey[]``（``Multikey``の配列をTypeScriptでこのように表記）形式を受け取るということだけ覚えておきましょう。\n\nところで、​``Person``オブジェクトには公開鍵を持つ属性が``publicKey``と``assertionMethods``の2つもあるのはなぜでしょうか？ActivityPubには元々``publicKey``属性しかありませんでしたが、​後から複数の鍵を登録できるように``assertionMethods``属性が追加されました。​先ほどRSA-PKCS#1-v1.5形式とEd25519形式の鍵を両方生成したのと同じような理由で、​様々なソフトウェアとの互換性のために両方の属性を設定しているのです。​よく見ると、​レガシーな属性である``publicKey``にはレガシーな鍵形式であるRSA-PKCS#1-v1.5鍵のみを登録していることがわかります。​（配列の最初の項目にRSA-PKCS#1-v1.5鍵ペアが、​2番目の項目にEd25519鍵ペアが入ります）\n\n[TIP]\n====\n実は``publicKey``属性も複数の鍵を含めることはできます。​しかし、​多くのソフトウェアが既に``publicKey``属性には単一の鍵しか入らないという前提で実装されているため、​誤動作することが多いのです。​これを避けるために``assertionMethods``という新しい属性が提案されたのです。\n\nこれに関して興味が湧いた方はlink:https://w3id.org/fep/521a[FEP-521a]文書を参照してください。\n====\n\n=== テスト\n\nさて、​アクターオブジェクトに暗号鍵を登録したので、​うまく動作するか確認しましょう。​次のコマンドでアクターを照会します。\n\n[source,console]\nfedify lookup http://localhost:8000/users/johndoe\n\n正常に動作すれば、​以下のような結果が出力されます：\n\n[listing]\n----\n✔ Looking up the object...\nPerson {\n  id: URL \"http://localhost:8000/users/johndoe\",\n  name: \"John Doe\",\n  url: URL \"http://localhost:8000/users/johndoe\",\n  preferredUsername: \"johndoe\",\n  publicKey: CryptographicKey {\n    id: URL \"http://localhost:8000/users/johndoe#main-key\",\n    owner: URL \"http://localhost:8000/users/johndoe\",\n    publicKey: CryptoKey {\n      type: \"public\",\n      extractable: true,\n      algorithm: {\n        name: \"RSASSA-PKCS1-v1_5\",\n        modulusLength: 4096,\n        publicExponent: Uint8Array(3) [ 1, 0, 1 ],\n        hash: { name: \"SHA-256\" }\n      },\n      usages: [ \"verify\" ]\n    }\n  },\n  assertionMethods: [\n    Multikey {\n      id: URL \"http://localhost:8000/users/johndoe#main-key\",\n      controller: URL \"http://localhost:8000/users/johndoe\",\n      publicKey: CryptoKey {\n        type: \"public\",\n        extractable: true,\n        algorithm: {\n          name: \"RSASSA-PKCS1-v1_5\",\n          modulusLength: 4096,\n          publicExponent: Uint8Array(3) [ 1, 0, 1 ],\n          hash: { name: \"SHA-256\" }\n        },\n        usages: [ \"verify\" ]\n      }\n    },\n    Multikey {\n      id: URL \"http://localhost:8000/users/johndoe#key-2\",\n      controller: URL \"http://localhost:8000/users/johndoe\",\n      publicKey: CryptoKey {\n        type: \"public\",\n        extractable: true,\n        algorithm: { name: \"Ed25519\" },\n        usages: [ \"verify\" ]\n      }\n    }\n  ],\n  inbox: URL \"http://localhost:8000/users/johndoe/inbox\",\n  endpoints: Endpoints { sharedInbox: URL \"http://localhost:8000/inbox\" }\n}\n----\n\n``Person``オブジェクトの``publicKey``属性にRSA-PKCS#1-v1.5形式の``CryptographicKey``オブジェクトが1つ、​``assertionMethods``属性にRSA-PKCS#1-v1.5形式とEd25519形式の``Multikey``オブジェクトが2つ入っていることが確認できます。\n\n== Mastodonとの連携\n\nこれで実際のMastodonから我々が作成したアクターを見ることができるか確認してみましょう。\n\n=== 公開インターネットに露出\n\n残念ながら、​現在のサーバーはローカルでのみアクセス可能です。​しかし、​コードを修正するたびにどこかにデプロイしてテストするのは不便です。​デプロイせずにすぐにローカルサーバーをインターネットに公開してテストできれば良いでしょう。\n\nここで、​``fedify tunnel``がそのような場合に使用するコマンドです。​ターミナルで新しいタブを開き、​このコマンドの後にローカルサーバーのポート番号を入力します：\n\n[source,console]\n$ fedify tunnel 8000\n\nそうすると、​一度使って捨てるドメイン名を作成し、​ローカルサーバーに中継します。​外部からもアクセス可能なURLが出力されます：\n\n[listing]\n----\n✔ Your local server at 8000 is now publicly accessible:\n\nhttps://temp-address.serveo.net/\n\nPress ^C to close the tunnel.\n----\n\nもちろん、​皆さんには上記のURLとは異なる皆さん独自のユニークなURLが出力されているはずです。​ウェブブラウザで\u003chttps://temp-address.serveo.net/users/johndoe\u003e（皆さんの固有の一時ドメインに置き換えてください）を開いて、​きちんとアクセスできるか確認できます：\n\n.公開インターネットに露出されたプロフィールページ\nimage::profile-page-2.png[公開インターネットに露出されたプロフィールページ]\n\n上記のウェブページに表示されている皆さんのフェディバースハンドルをコピーした後、​Mastodonに入って左上にある検索ボックスに貼り付けて検索してみてください：\n\n.Mastodonでフェディバースハンドルで検索した結果\nimage::search-results.png[Mastodonでフェディバースハンドルで検索した結果]\n\n上記のように検索結果に我々が作成したアクターが表示されれば正常です。​検索結果でアクターの名前をクリックしてプロフィールページに入ることもできます：\n\n.Mastodonで見るアクターのプロフィール\nimage::remote-profile.png[Mastodonで見るアクターのプロフィール]\n\nしかし、​ここまでです。​まだフォローはできないので試さないでください！他のサーバーから我々が作成したアクターをフォローできるようにするには、​インボックスを実装する必要があります。\n\nNOTE: ``fedify tunnel``コマンドは、​しばらく使わないと自動的に接続が切断されます。​その場合は、​kbd:[Ctrl+C]キーを押して終了させ、​``fedify tunnel 8000``コマンドを再入力して新しい接続を結ぶ必要があります。\n\n== インボックス\n\nActivityPubにおいて、​インボックス（inbox）はアクターが他のアクターからアクティビティを受け取るエンドポイントです。​すべてのアクターは自身のインボックスを持っており、​これはHTTP ``POST``リクエストを通じてアクティビティを受け取ることができるURLです。​他のアクターがフォローリクエストを送ったり、​投稿を作成したり、​コメントを追加したりなどの相互作用を行う際、​該当するアクティビティは受信者のインボックスに届けられます。​サーバーはインボックスに入ってきたアクティビティを処理し、​適切に応答することで他のアクターと通信し、​連合ネットワークの一部として機能するようになります。\n\nインボックスは様々な種類のアクティビティを受信できますが、​今はフォローリクエストを受け取ることから実装を始めましょう。\n\n=== テーブルの作成\n\n自分をフォローしているアクター（フォロワー）と自分がフォローしているアクター（フォロー中）を格納するために__src/schema.sql__ファイルに``follows``テーブルを定義します：\n\n[source,sql]\n----\nCREATE TABLE IF NOT EXISTS follows (\n  following_id INTEGER          REFERENCES actors (id),\n  follower_id  INTEGER          REFERENCES actors (id),\n  created      TEXT    NOT NULL DEFAULT (CURRENT_TIMESTAMP)\n                                CHECK (created \u003c\u003e ''),\n  PRIMARY KEY (following_id, follower_id)\n);\n----\n\n今回も__src/schema.sql__を実行して``follows``テーブルを作成しましょう：\n\n[source,console]\n$ sqlite3 microblog.sqlite3 \u003c src/schema.sql\n\n__src/schema.ts__ファイルを開き、​``follows``テーブルに保存されるレコードをJavaScriptで表現するための型も定義します：\n\n[source,typescript]\n----\nexport interface Follow {\n  following_id: number;\n  follower_id: number;\n  created: string;\n}\n----\n\n=== ``Follow``アクティビティの受信\n\nこれでインボックスを実装する番です。​実は、​すでに__src/federation.ts__ファイルに次のようなコードを書いていました：\n\n[source,typescript]\nfederation.setInboxListeners(\"/users/{identifier}/inbox\", \"/inbox\");\n\n上記のコードを修正する前に、​Fedifyが提供する``Accept``および``Follow``クラスと``getActorHandle()``関数を``import``します：\n\n[source,typescript,highlight=2,4,9]\n----\nimport {\n  Accept,\n  Endpoints,\n  Follow,\n  Person,\n  createFederation,\n  exportJwk,\n  generateCryptoKeyPair,\n  getActorHandle,\n  importJwk,\n} from \"@fedify/fedify\";\n----\n\nそして``setInboxListeners()``メソッドを呼び出すコードを以下のように修正します：\n\n[source,typescript]\n----\nfederation\n  .setInboxListeners(\"/users/{identifier}/inbox\", \"/inbox\")\n  .on(Follow, async (ctx, follow) =\u003e {\n    if (follow.objectId == null) {\n      logger.debug(\"The Follow object does not have an object: {follow}\", {\n        follow,\n      });\n      return;\n    }\n    const object = ctx.parseUri(follow.objectId);\n    if (object == null || object.type !== \"actor\") {\n      logger.debug(\"The Follow object's object is not an actor: {follow}\", {\n        follow,\n      });\n      return;\n    }\n    const follower = await follow.getActor();\n    if (follower?.id == null || follower.inboxId == null) {\n      logger.debug(\"The Follow object does not have an actor: {follow}\", {\n        follow,\n      });\n      return;\n    }\n    const followingId = db\n      .prepare\u003cunknown[], Actor\u003e(\n        `\n        SELECT * FROM actors\n        JOIN users ON users.id = actors.user_id\n        WHERE users.username = ?\n        `,\n      )\n      .get(object.identifier)?.id;\n    if (followingId == null) {\n      logger.debug(\n        \"Failed to find the actor to follow in the database: {object}\",\n        { object },\n      );\n    }\n    const followerId = db\n      .prepare\u003cunknown[], Actor\u003e(\n        `\n        -- フォロワーアクターレコードを新規追加するか、​既にあれば更新\n        INSERT INTO actors (uri, handle, name, inbox_url, shared_inbox_url, url)\n        VALUES (?, ?, ?, ?, ?, ?)\n        ON CONFLICT (uri) DO UPDATE SET\n          handle = excluded.handle,\n          name = excluded.name,\n          inbox_url = excluded.inbox_url,\n          shared_inbox_url = excluded.shared_inbox_url,\n          url = excluded.url\n        WHERE\n          actors.uri = excluded.uri\n        RETURNING *\n        `,\n      )\n      .get(\n        follower.id.href,\n        await getActorHandle(follower),\n        follower.name?.toString(),\n        follower.inboxId.href,\n        follower.endpoints?.sharedInbox?.href,\n        follower.url?.href,\n      )?.id;\n    db.prepare(\n      \"INSERT INTO follows (following_id, follower_id) VALUES (?, ?)\",\n    ).run(followingId, followerId);\n    const accept = new Accept({\n      actor: follow.objectId,\n      to: follow.actorId,\n      object: follow,\n    });\n    await ctx.sendActivity(object, follower, accept);\n  });\n----\n\nさて、​コードをじっくり見てみましょう。​``on()``メソッドは特定の種類のアクティビティが受信された時に取るべき行動を定義します。​ここでは、​フォローリクエストを意味する``Follow``アクティビティが受信された時にデータベースにフォロワー情報を記録した後、​フォローリクエストを送ったアクターに対して承諾を意味する``Accept(Follow)``アクティビティを返信として送るコードを作成しました。\n\n``follow.objectId``にはフォロー対象のアクターのURIが入っているはずです。​``parseUri()``メソッドを通じて、​この中に入っているURIが我々が作成したアクターを指しているかを確認します。\n\n``getActorHandle()``関数は与えられたアクターオブジェクトからフェディバースハンドルを取得して文字列を返します。\n\nフォローリクエストを送ったアクターに関する情報が``actors``テーブルにまだない場合は、​まずレコードを追加します。​すでにレコードがある場合は最新のデータで更新します。​その後、​``follows``テーブルにフォロワーを追加します。\n\nデータベースへの記録が完了すると、​``sendActivity()``メソッドを使ってアクティビティを送ったアクターに``Accept(Follow)``アクティビティを返信として送ります。​第一パラメータに送信者、​第二パラメータに受信者、​第三パラメータに送信するアクティビティオブジェクトを受け取ります。\n\n=== ActivityPub.Academy\n\nさて、​それではフォローリクエストが正しく受信されるか確認しましょう。\n\n通常のMastodonサーバーでテストしても問題ありませんが、​アクティビティがどのように行き来するか具体的に確認できるlink:https://activitypub.academy/[ActivityPub.Academy]サーバーを利用することにします。​ActivityPub.Academyは教育およびデバッグ目的の特殊なMastodonサーバーで、​クリック一つで簡単に一時的なアカウントを作成できます。\n\n.ActivityPub.Academyの最初のページ\nimage::academy.jpg[ActivityPub.Academyの最初のページ]\n\nプライバシーポリシーに同意した後、​btn:[登録する]ボタンを押して新しいアカウントを作成します。​作成されたアカウントはランダムに生成された名前とハンドルを持ち、​一日が経過すると自動的に消えます。​代わりに、​アカウントは何度でも新しく作成できます。\n\nログインが完了したら、​画面の左上にある検索ボックスに我々が作成したアクターのハンドルを貼り付けて検索します：\n\n.ActivityPub.Academyで我々が作成したアクターのハンドルで検索した結果\nimage::academy-search-results.png[ActivityPub.Academyで我々が作成したアクターのハンドルで検索した結果]\n\n我々が作成したアクターが検索結果に表示されたら、​右側にあるフォローボタンを押してフォローリクエストを送ります。​そして右側のメニューからbtn:[Activity Log]をクリックします：\n\n.ActivityPub.AcademyのActivity Log\nimage::activity-log.png[ActivityPub.AcademyのActivity Log]\n\nすると、​先ほどフォローボタンを押したことでActivityPub.Academyサーバーから我々が作成したアクターのインボックスに``Follow``アクティビティが送信されたという表示が見えます。​右下のbtn:[show source]をクリックするとアクティビティの内容まで見ることができます：\n\n.Activity Logでbtn:[show source]を押した画面\nimage::activity-log-2.png[Activity Logでshow sourceを押した画面]\n\n=== テスト\n\nアクティビティがきちんと送信されたことを確認したので、​実際に我々が書いたインボックスコードがうまく動作したか確認する番です。​まず``follows``テーブルにレコードがきちんと作成されたか見てみましょう：\n\n[source,console]\n$ echo \"SELECT * FROM follows;\" | sqlite3 -table microblog.sqlite3\n\nフォローリクエストがきちんと処理されていれば、​次のような結果が出力されるはずです（もちろん、​時刻は異なるでしょう）：\n\n[cols=\"1,1,1\"]\n|===\n| `following_id` | `follower_id` | `created`\n\n| `1`\n| `2`\n| `2024-09-01 10:19:41`\n|===\n\n果たして``actors``テーブルにも新しいレコードができたか確認してみましょう：\n\n[source,console]\n$ echo \"SELECT * FROM actors WHERE id \u003e 1;\" | sqlite3 -table microblog.sqlite3\n\n[cols=\"1,1,1,1,1,1,1,1,1\"]\n|===\n| `id` | `user_id` | `uri` | `handle` | `name` | `inbox_url` | `shared_inbox_url` | `url` | `created`\n\n|`2`\n|\n|`https://activitypub.academy/users/dobussia_dovornath`\n|`@dobussia_dovornath@activitypub.academy`\n|`Dobussia Dovornath`\n|`https://activitypub.academy/users/dobussia_dovornath/inbox`\n|`https://activitypub.academy/inbox`\n|`https://activitypub.academy/@dobussia_dovornath`\n|`2024-09-01 10:19:41`\n|===\n\n再び、​ActivityPub.AcademyのActivity Logを見てみましょう。​我々が作成したアクターから送られた``Accept(Follow)``アクティビティがきちんと到着していれば、​以下のように表示されるはずです：\n\n.Activity Logに表示された``Accept(Follow)``アクティビティ\nimage::activity-log-3.png[Activity Logに表示されたAccept(Follow)アクティビティ]\n\nさて、​これで皆さんは初めてActivityPubを通じた相互作用を実装しました！\n\n== フォロー解除\n\n他のサーバーのアクターが我々が作成したアクターをフォローした後、​再び解除するとどうなるでしょうか？link:https://activitypub.academy/[ActivityPub.Academy]で試してみましょう。​先ほどと同様に、​ActivityPub.Academyの検索ボックスに我々が作成したアクターのフェディバースハンドルを入力して検索します：\n\n.ActivityPub.Academyの検索結果\nimage::academy-search-results-2.png[ActivityPub.Academyの検索結果]\n\nよく見ると、​アクター名の右側にあったフォローボタンの場所にフォロー解除（unfollow）ボタンがあります。​このボタンを押してフォローを解除した後、​Activity Logに入ってどのようなアクティビティが送信されるか確認してみましょう：\n\n.送信された``Undo(Follow)``アクティビティが表示されているActivity Log\nimage::activity-log-4.png[送信されたUndo(Follow)アクティビティが表示されているActivity Log]\n\n上のように``Undo(Follow)``アクティビティが送信されました。​右下のbtn:[show source]を押すとアクティビティの詳細な内容を見ることができます：\n\n[source,json]\n----\n{\n  \"@context\": \"https://www.w3.org/ns/activitystreams\",\n  \"id\": \"https://activitypub.academy/users/dobussia_dovornath#follows/3283/undo\",\n  \"type\": \"Undo\",\n  \"actor\": \"https://activitypub.academy/users/dobussia_dovornath\",\n  \"object\": {\n    \"id\": \"https://activitypub.academy/98b131b8-89ea-49ba-b2bd-3ee0f5a87694\",\n    \"type\": \"Follow\",\n    \"actor\": \"https://activitypub.academy/users/dobussia_dovornath\",\n    \"object\": \"https://temp-address.serveo.net/users/johndoe\"\n  }\n}\n----\n\n上のJSONオブジェクトを見ると、​``Undo(Follow)``アクティビティの中に先ほどインボックスに入ってきた``Follow``アクティビティが含まれていることがわかります。​しかし、​インボックスで``Undo(Follow)``アクティビティを受信した時の動作を何も定義していないため、​何も起こりませんでした。\n\n=== ``Undo(Follow)``アクティビティの受信\n\nフォロー解除を実装するために__src/federation.ts__ファイルを開き、​Fedifyが提供する``Undo``クラスを``import``します：\n\n[source,typescript,highlight=6]\n----\nimport {\n  Accept,\n  Endpoints,\n  Follow,\n  Person,\n  Undo,\n  createFederation,\n  exportJwk,\n  generateCryptoKeyPair,\n  getActorHandle,\n  importJwk,\n} from \"@fedify/fedify\";\n----\n\nそして``on(Follow, ...)``の後に続けて``on(Undo, ...)``を追加します：\n\n[source,typescript,highlight=6..23]\n----\nfederation\n  .setInboxListeners(\"/users/{identifier}/inbox\", \"/inbox\")\n  .on(Follow, async (ctx, follow) =\u003e {\n    // ... 省略 ...\n  })\n  .on(Undo, async (ctx, undo) =\u003e {\n    const object = await undo.getObject();\n    if (!(object instanceof Follow)) return;\n    if (undo.actorId == null || object.objectId == null) return;\n    const parsed = ctx.parseUri(object.objectId);\n    if (parsed == null || parsed.type !== \"actor\") return;\n    db.prepare(\n      `\n      DELETE FROM follows\n      WHERE following_id = (\n        SELECT actors.id\n        FROM actors\n        JOIN users ON actors.user_id = users.id\n        WHERE users.username = ?\n      ) AND follower_id = (SELECT id FROM actors WHERE uri = ?)\n      `,\n    ).run(parsed.identifier, undo.actorId.href);\n  });\n----\n\n今回はフォローリクエストを処理する時よりもコードが短くなっています。​``Undo(Follow)``アクティビティの中に入っているのが``Follow``アクティビティかどうか確認した後、​``parseUri()``メソッドを使って取り消そうとしている``Follow``アクティビティのフォロー対象が我々が作成したアクターかどうか確認し、​``follows``テーブルから該当するレコードを削除します。\n\n=== テスト\n\n先ほどlink:https://activitypub.academy/[ActivityPub.Academy]でフォロー解除ボタンを押してしまったので、​もう一度フォロー解除をすることはできません。​仕方がないので再度フォローした後、​フォロー解除してテストする必要があります。​しかしその前に、​``follows``テーブルを空にする必要があります。​そうしないと、​フォローリクエストが来た時に既にレコードが存在するためエラーが発生してしまいます。\n\n``sqlite3``コマンドを使用して``follows``テーブルを空にしましょう：\n\n[source,console]\n$ echo \"DELETE FROM follows;\" | sqlite3 microblog.sqlite3\n\nそして再度フォローボタンを押した後、​データベースを確認します：\n\n[source,console]\n$ echo \"SELECT * FROM follows;\" | sqlite3 -table microblog.sqlite3\n\nフォローリクエストがきちんと処理されていれば、​次のような結果が出力されるはずです：\n\n[cols=\"1,1,1\"]\n|===\n| `following_id` | `follower_id` | `created`\n\n| `1`\n| `2`\n| `2024-09-02 01:05:17`\n|===\n\nそして再度フォロー解除ボタンを押した後、​データベースをもう一度確認します：\n\n[source,console]\n$ echo \"SELECT count(*) FROM follows;\" | sqlite3 -table microblog.sqlite3\n\nフォロー解除リクエストがきちんと処理されていれば、​レコードが消えているので次のような結果が出力されるはずです：\n\n[cols=\"1\"]\n|===\n| `count(*)`\n\n| `0`\n|===\n\n== フォロワーリスト\n\n毎回フォロワーリストを``sqlite3``コマンドで見るのは面倒なので、​ウェブでフォロワーリストを見られるようにしましょう。\n\nまず__src/views.tsx__ファイルに新しいコンポーネントを追加することから始めます。​``Actor``型を``import``してください：\n\n[source,typescript]\nimport type { Actor } from \"./schema.ts\";\n\nそして``\u003cFollowerList\u003e``コンポーネントと``\u003cActorLink\u003e``コンポーネントを定義します：\n\n[source,tsx]\n----\nexport interface FollowerListProps {\n  followers: Actor[];\n}\n\nexport const FollowerList: FC\u003cFollowerListProps\u003e = ({ followers }) =\u003e (\n  \u003c\u003e\n    \u003ch2\u003eフォロワー\u003c/h2\u003e\n    \u003cul\u003e\n      {followers.map((follower) =\u003e (\n        \u003cli key={follower.id}\u003e\n          \u003cActorLink actor={follower} /\u003e\n        \u003c/li\u003e\n      ))}\n    \u003c/ul\u003e\n  \u003c/\u003e\n);\n\nexport interface ActorLinkProps {\n  actor: Actor;\n}\n\nexport const ActorLink: FC\u003cActorLinkProps\u003e = ({ actor }) =\u003e {\n  const href = actor.url ?? actor.uri;\n  return actor.name == null ? (\n    \u003ca href={href} class=\"secondary\"\u003e\n      {actor.handle}\n    \u003c/a\u003e\n  ) : (\n    \u003c\u003e\n      \u003ca href={href}\u003e{actor.name}\u003c/a\u003e{\" \"}\n      \u003csmall\u003e\n        (\n        \u003ca href={href} class=\"secondary\"\u003e\n          {actor.handle}\n        \u003c/a\u003e\n        )\n      \u003c/small\u003e\n    \u003c/\u003e\n  );\n};\n----\n\n``\u003cActorLink\u003e``コンポーネントは1つのアクターを表現するのに使用され、​``\u003cFollowerList\u003e``コンポーネントは``\u003cActorList\u003e``コンポーネントを使用してフォロワーリストを表現するのに使用されます。​ご覧の通り、​JSXには条件文や繰り返し文がないため、​三項演算子と``Array.map()``メソッドを使用しています。\n\nそれではフォロワーリストを表示するエンドポイントを作成しましょう。​__src/app.tsx__ファイルを開いて``\u003cFollowerList\u003e``コンポーネントを``import``します：\n\n[source,typescript]\nimport { FollowerList, Layout, Profile, SetupForm } from \"./views.tsx\";\n\nそして``GET /users/{username}/followers``に対するリクエストハンドラを追加します：\n\n[source,tsx]\n----\napp.get(\"/users/:username/followers\", async (c) =\u003e {\n  const followers = db\n    .prepare\u003cunknown[], Actor\u003e(\n      `\n      SELECT followers.*\n      FROM follows\n      JOIN actors AS followers ON follows.follower_id = followers.id\n      JOIN actors AS following ON follows.following_id = following.id\n      JOIN users ON users.id = following.user_id\n      WHERE users.username = ?\n      ORDER BY follows.created DESC\n      `,\n    )\n    .all(c.req.param(\"username\"));\n  return c.html(\n    \u003cLayout\u003e\n      \u003cFollowerList followers={followers} /\u003e\n    \u003c/Layout\u003e,\n  );\n});\n----\n\nそれでは、​うまく表示されるか確認してみましょう。​フォロワーがいるはずなので、​``fedify tunnel``を起動した状態で他のMastodonサーバーやlink:https://activitypub.academy/[ActivityPub.Academy]から我々が作成したアクターをフォローしましょう。​フォローリクエストが承認された後、​ウェブブラウザで\u003chttp://localhost:8000/users/johndoe/followers\u003eページを開くと、​以下のように表示されるはずです：\n\n.フォロワーリストページ\nimage::followers-list.png[フォロワーリストページ]\n\nフォロワーリストを作成したので、​プロフィールページでフォロワー数も表示すると良いでしょう。​__src/views.tsx__ファイルを再度開き、​``\u003cProfile\u003e``コンポーネントを以下のように修正します：\n\n[source,tsx,highlight=3,5,10,12,20..23]\n----\nexport interface ProfileProps {\n  name: string;\n  username: string;\n  handle: string;\n  followers: number;\n}\n\nexport const Profile: FC\u003cProfileProps\u003e = ({\n  name,\n  username,\n  handle,\n  followers,\n}) =\u003e (\n  \u003c\u003e\n    \u003chgroup\u003e\n      \u003ch1\u003e\n        \u003ca href={`/users/${username}`}\u003e{name}\u003c/a\u003e\n      \u003c/h1\u003e\n      \u003cp\u003e\n        \u003cspan style=\"user-select: all;\"\u003e{handle}\u003c/span\u003e \u0026middot;{\" \"}\n        \u003ca href={`/users/${username}/followers`}\u003e\n          {followers === 1 ? \"1 follower\" : `${followers} followers`}\n        \u003c/a\u003e\n      \u003c/p\u003e\n    \u003c/hgroup\u003e\n  \u003c/\u003e\n);\n----\n\n``ProfileProps``には2つのプロップが追加されました。​``followers``は文字通りフォロワー数を含むプロップです。​``username``はフォロワーリストへのリンクを張るためにURLに入れるユーザー名を受け取ります。\n\nそれでは再び__src/app.tsx__ファイルに戻り、​``GET /users/{username}``リクエストハンドラを次のように修正します：\n\n[source,tsx,highlight=5..15,21,23]\n----\napp.get(\"/users/:username\", async (c) =\u003e {\n  // ... 省略 ...\n  if (user == null) return c.notFound();\n\n  // biome-ignore lint/style/noNonNullAssertion: 常に1つのレコードを返す\n  const { followers } = db\n    .prepare\u003cunknown[], { followers: number }\u003e(\n      `\n      SELECT count(*) AS followers\n      FROM follows\n      JOIN actors ON follows.following_id = actors.id\n      WHERE actors.user_id = ?\n      `,\n    )\n    .get(user.id)!;\n  // ... 省略 ...\n  return c.html(\n    \u003cLayout\u003e\n      \u003cProfile\n        name={user.name ?? user.username}\n        username={user.username}\n        handle={handle}\n        followers={followers}\n      /\u003e\n    \u003c/Layout\u003e,\n  );\n});\n----\n\nデータベース内の``follows``テーブルのレコード数を数えるSQLが追加されました。​さて、​それでは変更されたプロフィールページを確認してみましょう。​ウェブブラウザで\u003chttp://localhost:8000/users/johndoe\u003eページを開くと以下のように表示されるはずです：\n\n.変更されたプロフィールページ\nimage::profile-page-3.png[変更されたプロフィールページ]\n\n== フォロワーコレクション\n\nしかし、​一つ問題があります。​ActivityPub.Academy以外の他のMastodonサーバーから我々が作成したアクターを照会してみましょう。​（照会方法はもうご存知ですよね？公開インターネットに露出された状態で、​アクターのハンドルをMastodonの検索ボックスに入力すれば良いのです）Mastodonで我々が作成したアクターのプロフィールを見ると、​おそらく奇妙な点に気づくでしょう：\n\n.Mastodonで照会した我々が作成したアクターのプロフィール\nimage::remote-profile-2.png[Mastodonで照会した我々が作成したアクターのプロフィール]\n\nフォロワー数が0と表示されているのです。​これは、​我々が作成したアクターがフォロワーリストをActivityPubを通じて公開していないためです。​ActivityPubでフォロワーリストを公開するには、​フォロワーコレクションを定義する必要があります。\n\n__src/federation.ts__ファイルを開いて、​Fedifyが提供する``Recipient``型を``import``します：\n\n[source,typescript,highlight=12]\n----\nimport {\n  Accept,\n  Endpoints,\n  Follow,\n  Person,\n  Undo,\n  createFederation,\n  exportJwk,\n  generateCryptoKeyPair,\n  getActorHandle,\n  importJwk,\n  type Recipient,\n} from \"@fedify/fedify\";\n----\n\nそして下の方にフォロワーコレクションディスパッチャーを追加します：\n\n[source,typescript]\n----\nfederation\n  .setFollowersDispatcher(\n    \"/users/{identifier}/followers\",\n    (ctx, identifier, cursor) =","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdahlia%2Ffedify-microblog-tutorial-ja","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdahlia%2Ffedify-microblog-tutorial-ja","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdahlia%2Ffedify-microblog-tutorial-ja/lists"}