小ネタ：ed25519秘密鍵公開鍵とJson serialized canonical
あちこちに散らばるとモノを探すだけのために時間を使っちゃうことになるんで、こっちにメモ。
【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系のパッケージは本体署名に対応してないんだけど、むしろこっちの方が合理的かもしれない。
様子見するけど、これって対応する必要がないと思ったなあ。どうなんだろ…
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
RFC9421版HTTP Signatureに対応
おひとり様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ぐらいで生活するのがいいってことでもありますなあ
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
HTTP Signatureの署名対象文字列
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」
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
web本棚のActivityPub対応
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(ここにはいません)を返すようにした。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
web本棚のソースコード公開
今まで、スクリプトのソースコードを晒すことはしてなかった。
いや、ぶっちゃけ、自分で見ても酷いありさまで、とてもひと様に見せるようなシロモノじゃないから。
そんなものを公開したところで、誰のためにもならない・誰の役にも立たない。
…ということなんだけど。
還暦も過ぎるといろいろ終活を考えなきゃいけない。
先日のエントリ 「web本棚」 でも終活の一環でサービス終了ということを書いていて、ちょっと考え直した。
書き散らかしてきたスクリプトを晒したところで誰のためにもならないけど
「晒すことで自分のやってきたことを自分でふりかえることになる」
のは、自分のためになる。単純に面白い。
ということでちょっとずつ晒してみようかとホームページに新コーナーを作った。
「On Golden Pond」
まずはweb本棚のソースコードを公開
「web本棚のソースコード::On Golden Pond」
もう20年ほど前に作って、改築増築改修をしてきたもの。
SQLもまだ覚えたてみたいな時で、今だったらjoinしてgroupingしてとかSQLだけで済ませられるようなことも、ひとつずつ抽出して、抽出した結果をperlで処理してる。
なかなか恥しいシロモノなんだけど、怪我の功名というかSQLが単純なので処理の切り分けがperlのところで済むので簡単に改修できる。
とはいえ問題がjavascriptとスタイルシート。
javascriptはjQueryなんか使っててそのままだし、スタイルシートがjQueryべったりで、スマホ対応が無理。これは諦めた。
・本棚を眺めてるというのにページ遷移なんかで読みこみが入るとうっとーしーからアクションを起こしてもその場から極力動かずに済むように
・没頭してると時間を忘れそうだから時計表示は必須だろうし
などなど、どうしても(当時としては)jQueryが必要だったんだよなあ。失敗だった。
ソースコードを公開するなら、今どきなら、プログラマ御用達のgithubやcodebergを使うんだろうけど、わたしはただの素人でプログラマではない。
それに不具合やリクエストが飛んできても対応できない…というか、その気もない。
文字通り、素人のクソコードを本職のプログラマが利用するようなサイトに掲載する度胸もないしね。
なので、自分のホームページでそっと公開することにした。
自分のホームページなら、何をするにしてもすべて自分の管理下、ほかの誰かに迷惑をかけることもないという気楽さもあるしね。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
web本棚
20年ほど前、2006年4月1日から公開しているweb本棚がある。
ブログブームがひと段落して、mixiなどのSNSが話題になって、次はSNSですよという頃だった。
既読/未読がわかって、本をダブって買わないために、という本棚を作ってたところで、それなら本棚の共有サイトを作ってサービス公開してみようというのが始まり。
『趣味は読書2』
図書館で本を借りて図書カードを見て
「あれ？あのコもこれ読んだのかぁ」とか「おっあいつこんなの読むんだ」と、ニマニマしたり
ひとんちに呼ばれたら、まず本棚を覗いて
「これ、わたしも読んだよ」と言いたくなったり
図書館とか本屋で、どの棚の前に立っているかで、そのひとの属性がわかって、うれしかったり
なんだか「ありきたり」な趣味なので履歴書にも書けない気がしたり
本を読んでも難しいことを考えたり感想文は面倒くさかったり
ヲタクだと思われそうで嫌だったり
でもって、だけど本好きとか本読みですが、なにか？
というようなことを、思ったことはありませんか？ ぼくは、あります。なので、そんな本棚のようなサイトを作ってみました。
たぶん、WEB本棚サービスとしては早い方だったと思う。500人弱のユーザーのかたの登録で、アクティブなユーザーさんは20人弱ほど。
最初は自宅のPCでサーバーを立てて公開して、311の震災をきっかけにレンタルサーバーに引越し。
現在もまだ稼動中なんだけど、新規登録を中止して、いま利用してるかただけの運用になっている。
ただ、わたしの還暦を過ぎた年齢的にもうそんなに長く続けられない。
んなこんなで、レンタルサーバーの契約が切れるタイミングでサービス終了することにした。
利用しているユーザーさん向けにサービス終了の告知とバックアップのお願いを表示。
とはいえ、せっかく登録・利用してもらってる本棚だし、バックアップではなくて本棚の復元ができるようにスクリプトを改修した。
ローカルPCでやるにはapacheやperlが必要だったり、web版(レンタルサーバー)だと有料だろうし、ハードルが高くなってしまったけど、復元手段を用意できたので案内と手順書も告知した。
どのぐらいのユーザーさんが使ってくれるか、難しいところだけど、これでひと安心。けっこう気になってたんだよね。
もともと、ユーザーさんの行動を見ると、本棚にアクセスして、登録したら離脱、というのが90%以上。
ほかのユーザーさんの本棚を見にいくとかお気に入りに登録するという「交流部分」はほぼほぼ使われてなかった。
上記したように、もともと「未読/既読」の確認のための本棚というのがスタート。
電子書籍なんかだと「購入履歴」が残るので、当初の役割がなくなってわたし自身があまり使わなくなっていた。
だいたい、老眼が酷くなってきて文字を読むのがつらくて読書量が激減してるんだけど。
とはいえ、シングル利用向けに作り直してみたら面白いんで、また使ってみようかと。
本棚なんて個人情報をネットで晒すのもどうなのと思われそうだけど、好きな本や映画のタイトルを並べて自己紹介がわり、ということもあるだろうし。
閲覧するだけならログイン不要の本棚ということにした。
『web本棚』
↑わたしの本棚…ほんとろくに読んでない(登録してない本もあるけど)
この際、せっかくだし「老眼鏡」を作ろう。
ちなみにweb版のスクリプト一式はこちら
https://bookshelf.doncha.net/arc/bookshelf.zip
ファイル、ディレクトリ構造そのまま。perlの実行属性を705か755にすれば動くと思います。
v1.0.1[[2026/01/05 15:57:31]]
・kindle本の登録ができなかったのを修正
・本の情報に取得できなかった場合のcache設定修正
ひとを巻き込んでサービスを公開するのはいいけど、終了させる方がいろいろ大変。
これもまた終活の一環だなあ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
