あちこちに散らばるとモノを探すだけのために時間を使っちゃうことになるんで、こっちにメモ。

【ED25519秘密鍵と公開鍵の作成】

opensslを使って作成する。RSAなどと同じ。

Linux Mint 22.3で作成

opensslのバージョン

OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)

まず秘密鍵を作る

openssl genpkey -algorithm ed25519 -out ed25519-sercret.key

作った秘密鍵を使って公開鍵を作る

openssl pkey -in ed25519-secret.key -pubout -out ed25519-pub.key

ActivityPubでActivityとObjectの署名に使える予定らしい

https://codeberg.org/fediverse/fep/src/branch/main/fep/8b32/fep-8b32.md

これをAcitvityPubのJSONで使うにはこのままではなくて、さらにpublicMultibase形式に変換する必要があるらしい

・BEGIN PUBLICK KEYとEND PUBLIC KEYの接頭辞を削除

・改行を削除

decode_base64でバイナリデータに戻して、base58形式に変換して使うとのこと。

pem形式からpublicMultibase形式に変換してJSONに登録

署名する時はpublicMultibase形式からpem形式に戻して署名

検証する時も同じことを…って、すげー手間だな、これ。

【Json serialized canonical】

ActivityPubの本体のJSONを対象に署名する必要がある。

現状2種類あるらしい。

・Mastodonが実装している Linked Data Signatures

https://docs.joinmastodon.org/spec/security/#ld

・FEP-8b32 で提案されている Integrity proofs

https://amasecocoa.github.io/fep/8b32/

Mastodonが採用してるやつは古い仕様で、公式自体が非推奨だし、複雑怪奇の伏魔殿。かかわりたくない。

FEP-8b32がこれから使われると思うけど、これはこれで現在仕様検討のdraft状態で現状の決定ではない。

将来的にFEP 8B32になると想定して検討するとして、やっぱり具体的に署名対象ってどれで、それをどうすんの問題。

ActivityのJSONをcanonicalしてserializeしたものを対象にする、とのこと。

なにそれ？だったんだけど「日本語でどうぞ」だった。

canonical

→キーを辞書順に並べる

serialize

→文字列にする

※改行や空白、インデントなどは不要なので削除

perlのJSONの場合は

$json=JSON->new->canonical(1)->utf8(1)->indent(0)->space_before(0)->space_after(0)

で、OKのようだ。

ただ、perlの場合「0.00」というのが文字列の「0」になるんで、数値をそのまま数値として使うには「var+=0」などと明示的に数値にする必要がある、らしい。

【オチ】

ここまでダラダラとメモったのは、ActivityPubで本体に署名をするため。

本体に署名されていれば、本体の改竄検知に利用できるから。

これに対応することで、Mastodon系などはメンションの時に「転送」することができる。

いわゆる「ゴーストリプライ」問題の対応。

とはいえ、転送しなくてもAnnounceすれば同じこと。どっちで問題解決する？という程度の話だろう。

それより、この本体署名をつけることをMUSTにするには問題があると思っていて。

署名を認証するためには「公開鍵」が必要。actor(アカウント)が削除されたら「公開鍵」を取得できない。

(ActivityPubの仕様的に「転送」はMUSTだけど、本文署名は仕様にはないからややこしいんだけど)

なので、公開鍵はアカウントが削除された後もキャッシュされたりサーバーが一定期間保持したりするらしい。

「公開鍵」を取得できることが大前提。

いつまでキャッシュ・保持しなきゃいけないの？と言われても答えられないはず。本体に署名をつける意味ある？ということになるんじゃないかな。

Misskey系のパッケージは本体署名に対応してないんだけど、むしろこっちの方が合理的かもしれない。

様子見するけど、これって対応する必要がないと思ったなあ。どうなんだろ…

タイトル通り、ActivityPubは自作実装がおすすめ、というのが今回のエントリ。

ActivityPubとかフェディバース(Fediverse)とか言うとなんか難しそうだけど、ざっくり言うと2ちゃんねるにちょっと今どきの機能を追加した掲示板みたいなもんだ。

平成の頃のインターネット、レンタルサーバーにフリーの掲示板CGIをFTPでアップロードして設置したことのあるひとなら、何をしてるのかイメージしてもらえると思う。

ネットの記事なんかを見てみると。

ActivityPubを自作するのは大変なだけなのでやめた方がいい、そして、どうしても自分で設置したいならいろんな機能が用意されたパッケージやフレームワークを使うべき、らしい。

言いたいことは理解するけど、届けたい相手の設定を間違ってる。

そもそも、MastodonやMisskeyといったパッケージをインストールして設定できたり、フレームワークを利用してオリジナルなサーバーを立ち上げたりできるスキルを持っているひとなら、ActivityPubを自作する方が早いだろう。

もちろん、いろんなサーバーの機能フルスペックは難しいけど、「ひとりで使う」「欲しい機能を限定する」という前提でいうと、自由度の高い/最低限の仕様だけが決められているActivityPubはハードルが低くて思ってるより簡単。

わたしはperlだけで作ったけど、今どきならrubyやphpだけでもっと簡単に作れると思う。

なんならデータベースも不要だし、メールサーバーやキャシュサーバーも不要。

フロント側もWEBプッシュだの非同期で情報取得なんかも不要。F5で再読み込みするのが昔の掲示板の流儀。

perlやruby、phpといったレンタルサーバーでも利用できる、いわゆる軽量プログラミング言語ひとつで実装できる。ほかに必要なものはない。

そしてなにより、しょっちゅう引用させてもらってる

「Webhook的に ActivityPub に投稿する実装を作った」

オープンな仕様 ActivityPub の力を借りて自前実装で他の実装とつながれる体験は心躍るものがあり、テキストを発信するだけのBOTを動かすだけでも動いたときは感動を覚えた

ほんと、これにつきる。自作すればこの楽しみを全身で享受できる。

ここんとこのエントリで書いているHTTP Signatureが面倒くさいんだけど、ここさえクリアしてしまえば、あとは昔ながらの掲示板CGIと同じようなものだ。

ActivityPubの実装についてホームページにコーナーを作って紹介してます。よろしければどうぞ

「おひとり様ActivityPubサーバーの自作実装」

これだけのことで、自分だけの掲示板を持てるんだからActivityPubという仕様には大感謝!

[更新]2026-01-22 19:33:54

おひとり様AcitivityPubのHTTP SignatureでRFC9421対応したというのが今回のエントリ。

ActivityPubで(に限った話じゃないけど)何をするにしてもサイト、フェディバースの「入口」がここ。どこかにアクセスするには署名が必須となっている。前回のエントリに書いたように、Signiture周りはけっこう面倒くさいんで、あまり触りたくないところだ。

なんだけど、フェディバースで広く使われているMasutodonというサーバーソフトウェアがRFC9421版に対応して、使えるようになった。

それもあってか、これまで見なかったRF9421で署名されたリクエストが飛んできていてびっくり。ウチは対応できてなかったんでエラーを吐いてた。

…ということで慌ててRFC9421のSignatureに対応した。

ここの対応ができないようだと、入口で弾かれて中に入れない。めっちゃクリティカルなところだ。

このRF9421にいたるまでの経緯は紆余曲折あったみたいで、2020年にdraft版が公開されて正式版？のRFC9421になったのが2024年2月。4年以上draft版、言葉通り、暫定版で各サイトが運用していた、ということになる、のかな。

https://datatracker.ietf.org/doc/html/rfc9421

んなことはともかく。

仕様を調べて少し試行錯誤をしてどうにか対応することができた。

結局のところ、RFC9421のページを見て、実際に飛んでるリクエストと照しあわせてみれば、以前のdraft版とやることは変わりがない。思ったよりすんなり実装できた。

ここを対応できないようだとせっかくのフェディバース生活が終わってしまう。

ということもあって、たぶんシェアNo.1のMastodonのアップデート情報をチェックしていて良かった。Signature周りで変更がある、ということは去年の時点で検知してたんだけど、実際広く使われてるのはdraft版のほうだしと安心しつつ、ビビっていつも以上に要観察してた。

早速、というか忘れないうちにホームページに追加した。

「Fediverseに参加するための最低条件2::On Golden Pond」

ActivityPubを喋ってフェディバースに参加するためには、Mastodonなど広く使われていて実績のあるソフトウェアがある。そちらではRFC9421済みで、今回のわたしのように右往左往する必要はない。

だけど、そういったサーバーソフトウェアを使っていて、もしそれが対応していなかったら、わたしはお手上げ。その時点でいろいろ終了だ。

うちのActivityPub自作実装は「自分のわかる範囲」だけ。

今回のことも面倒くさい…だけど、わかってるんで面倒くさいだけで対応は可能。自作実装したメリットがちょっとはあった、かな。

歳くったら、手の届く範囲、身の回り50cmぐらいで生活するのがいいってことでもありますなあ

2023年にActivityPubを自作実装した時に、うまく意図通りにいかなくて悶絶したのがHTTP Signatureの作成と認証確認。

検索しまくって何度も何度も試行錯誤した。

RSAというかCryptは今もよくわからないまま。

「Crypt::Perl - Cryptography in pure Perl」

↑META::CPANで公開されているモジュールをありがたく使わせてもらっている。

「HTTP Signatureをlolipopレンタルサーバーで作成」 にも書いたけど、このモジュールはpure perl、すべてperlだけで書かれている。

perlを使えるサーバーだったらどこでも、誰でもインストールして使えるのが素晴しい。

phpやruby、pythonを使えるサーバーも増えてきてるとはいえ、たぶんまだ全部のサーバー、特にレンタルサーバーで使えるとは限らない。

だけど、perlが使えないサーバーなど存在しない、はず。

で、ここからが今回のエントリ…本題に入るまでが長いのは老人特有の症状。

・HTTPヘッダに署名をつけてリクエストをする必要があるのはわかった。

・署名するためのモジュールも使い方はわかった。

わからなかったのが「んじゃそれって、いったい何を対象に署名するの？」というところ。

結局、HTTPヘッダなど、環境変数で取れるもので署名の対象を作るんだけど、今度はそれをどんな形で検証生成のモジュールに渡せばいいのかがわからない。

具体例を探して右往左往。

必要とされる環境変数の「キー」と「値」を「コロンと半角空白」で繋いだ文字列にして集めて、その文字列を最後に「改行」で繋いだ文字列にしたものが、署名の対象となる。

署名の生成認証は対象となる文字がひとつでも違ってたら通らない。

厳密厳格なのが当たり前。

余計な空白やダブルクオート、セミコロンなんかが入ってることに気づかない自分の雑な性格を呪う日々だった。

なもんで、あまり触りたくない、のが本音。

web本棚をActivityPub対応した時に、このSignatureまわりをすっかり忘れてたので復習。

具体的なコードはホームページに掲載した。

「HTTP Signatureの解析::On Golden Pond」

[更新]2026-02-01 09:03:21

web本棚のネタが続いてます。今回はweb本棚のActivityPub対応ネタ。

フェディバースからアカウントとして認識されて、フェディバースに投稿できるようにした。

以前、ツイッターだった頃、APIがまだ使えた頃、web本棚をツイッター連携対応させていた。

web本棚アカウントにタイトルや著者名をツイートすると、本棚を検索して結果を返信ツイートする、というもの。

web本棚はちゃんとしたスマホ対応をしてない。本の重複購入を避けるため、というのが一番の目的で、街の本屋さんをぶらぶら眺めていて、ツイッターに検索を投げて本を確認する、というのが思った以上に便利だった。

てことで、ツイッターでやってたことと同じことをActivityPubに対応させてフェディバースでもできるようにした。

まずはフェディバースからアカウントとして認識させる。

・nodeinfo

・nodeinfo/2.1

・host-meta

・webfinger

・アカウント情報のJSON

以上5つのファイルを静的に作成。アクセスされた時にmimetypeのヘッダを付与する必要があるので、perlで読みこんで返すことにした。

すでに稼働中のおひとり様AcitvityPubで使ってるファイルをちょっと編集して配置するだけなのでそんなに大変でもなかった。

どっちかというとプロフィール画像とカバー画像を選ぶのに2時間以上かかってる…て、そんなものだろう。

スクリーンショットはmastodon.socialでweb本棚のアカウント「@librarian@bookshelf.doncha.net」(司書)を検索して表示したもの。

このアカウントは自分の本棚を検索してその結果を返すのが役割。自分の本棚専門、自分専属の司書さんみたいなものだ。

なので、ローカルのタイムラインなども不要だし、投稿内容を保持する必要もない。フォローもフォロワーもない。

フェディバースを経由すると言っても、本棚にDMをリクエストするだけ、リクエストを受けとったら本棚を検索して結果をDMで返すだけで、ほかのサーバーに余計な手間・負荷もかけない。

フェディバースを利用する意味があるのか、ということかもしれないけど。

HTTP Signatureで署名してActivityを投げて、そのActivityにいちいち意味があって、という「仕組み」が用意されているのがありがたい。ゼロから考えてなにかを作るのはやっぱしんどい。せっかくよくできた仕組みがあるんだから乗らない手はない、ということ。

↑実際に司書さんにDMをリクエストして、返信のDMをもらったところ

おひとり様のAcitivityPubとは違って、実装も考えるところが少なくて済んだ。

通信する相手が自分だけなんだから当たり前。がっつりいろんなところを省いた。botなんかもこんな感じで作れるんだろなあ。

老眼鏡も作ったことだし、今回改めて本棚の体裁も整ったし、また紙の本を読もう。

[2026/01/10 08:01:33] 追記

フェディバースにアカウントとして認識されると、

「新入りがおるみたいやな、情報を送ったる」

と、リクエストが飛んでくるようになる(actorのDeleteなど)

web本棚はSNS的な利用を考えていない、わたし専属。

なので、わたし以外からのリクエスト(POST)に対しては404(ここにはいません)を返すようにした。