ブログをレスポンシブ対応にリニューアル

2026/1/29 [21:38:32] (木) 天気

今回のエントリはタイトル通り、ブログをレスポシブ対応にリニューアルした!

このブログ、ひまつぶし雑記帖は前回のエントリに書いたように、もはや前世紀の遺物。

いちおう、スマホ対応はしてたとはいえ、UserAgentを見ていろいろ振り分け。このUAを見るというのは、どうやらそろそろ限界らしいという噂がここ何年も続いてた。

今どきのレスポンシブ対応にしておかないとまずいなあ、と思ってたんだけど気が重くて放置状態だった。


最近、個人ブログを読むのが楽しくなってきていて

「ミンゲイインターネット」

↑こちらからいろんなひとのブログを訪問してる。

みなさん、情報も適当適切だし、レスポンシブだし、それと比べるとウチはとっちらかってるし…というのを思い知らされたり。


てことで、ブログを作り直すことにした。

レスポンシブ対応が一番だけど、20年ものだしあちこちガタガタ。


特にデータベースは、ド素人。スクリプトを見るとalter table addなんちゃらがあちこちにあってのけぞる。

とはいえ、素人なりにいろいろ考えてたらしい自分はちょっと頑張ってたかも。

最初は新しく作って過去の遺物は廃棄、と思ってたんだけど、昔の自分に止められて過去分を引き継いでリニューアルということにした。


今は亡きツイッターだのfacebook、mixi対応までしていてスクリプトのあちこちに産廃、ガレキの山もあって、これらも掃除するいい機会だ。


データベースを新規に作ると、今までのURLにも影響する。

SEOというやつがもはや意味をなさないらしいんで、気にすることもない。ただ、リンクを貼られてるエントリもあるんで、対応は必要。

rewrite ruleでやると、身動きできなくなることも考えられるんで、スクリプトに仕込み。


久しぶりにSQLを書いたのは、ボケ防止になったかも。perlは相変わらず面白いし。

image

30年ぐらい前にLibrettoを自宅サーバーにして公開してたこともあったなあ

ブログのふり返り

2026/1/26 [08:10:43] (月) 天気

この雑記帖の見直しというか、ふり返りが今回のエントリ。


1998年から始めた雑記帖。当初はHTMLを書いてFTPでレンサバにアップロード。

過去ログの一覧からもわかるように、投稿数が、1998年は18件、1999年は3件と、ほとんど更新もない状態だった。

2000年にCGIにしてから激増。テキストエリアに本文を入力して、csvで保存というもの。それでも気楽に書きこめるんでそれこそ日記状態。んなもんインターネットに公開してどうすんの、というもの。

2004年に20年勤めた底辺エロ本屋を退職して生活環境も変わったので、ついでに今のブログ形態にリニューアル。


この頃からちょっとずつ投稿内容について考えるようになった。


日常雑記、1mmも有用な情報のない投稿はさすがにまずいかなあ、と。

perlやサーバー周りなんかのIT(それ)っぽいネタを多めに、できるだけ詳細に情報元URLなども具体的に書くようにこころがけた。

無職&転職を繰り返すことになるんで、ブログが仕事に繋ればありがたいという 下心 目論見もあったしね。


ありがたいことに電子書籍制作やweb制作で個人のかたや制作会社からブログ経由で声をかけていただいて、実際に仕事になった。


これはこれでいいんだけど、無駄なことがスポイルされるのもどうなんだろうと改めて思った。

というのも、つい先日フェディバースでわたしとしては多くのリアクションをもらった投稿


[6971] 2026/01/25[07:59]
>草の根BBSじゃないけど、草の根SNS・せいぜい1000〜3000人規模のSNSが乱立して繋がっていくと面白そうだよね。

2005年、20年前の自分のブログにアクセスがあって、?と思って見てみたら…自画自賛していいっすかw

「サーバーとデータベース知識も必須か::ひまつぶし雑記帖」

https://t2aki.doncha.net/?id=1134732831

↑元の雑記がこれなんだけど、頑張ってサーバーとかデータベースを勉強するぞ! という主旨のところじゃなくて、飲み屋のカウンターで酔っ払いがなんか言ってるぞレベルのネタのところがリアクション対象。

世の中や人生において「無駄になることなどひとつもない」というのが仙人に弟子入りテンプレートで、たぶんそういうことだと思う。


技術系のネタなんて、すぐに古くなって使いものにならなくなるけど、酔っ払いのヨタ話は意外と普遍性があるということかもしれない。


ということで? 今年はもう65歳だしブログで頑張るのも限界だろうから、テキトーな与太も書き散らかして終活としよう。


image

何度も書いてるけど。歳くったら

「身の回り半径50cm、前後5分」

ぐらいが、ちょうどいい塩梅ってやつだよなあ

小ネタ:ed25519秘密鍵公開鍵とJson serialized canonical

2026/1/21 [14:51:21] (水) 天気

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


【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系のパッケージは本体署名に対応してないんだけど、むしろこっちの方が合理的かもしれない。


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

image

ActivityPubは自作実装しよう!

2026/1/20 [19:10:22] (火) 天気

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


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


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


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

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


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


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

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


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

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

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


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


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

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

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

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


image

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


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

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


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

RFC9421版HTTP Signatureに対応

2026/1/17 [18:47:40] (土) 天気

おひとり様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自作実装は「自分のわかる範囲」だけ。

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


image

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

<<2026/1>>
    123
45678910
11121314151617
18192021222324
25262728293031
検索:

【最近の20件】