インターネット辺境の個人サイト生活
レンタルサーバーで自分のスペース(居場所)を確保して、ドメイン(名前)を取得して、インターネットで遊ぶのは楽しいし、なによりほぼ自分の管理下なので安心安全でいいよねー
というのが今回のエントリ、というか公開してる自分のサイトの棚卸し＆自画自賛。
わたしが「doncha.net」という個人サイトを始めたのは、2007年4月。
ロリポップでレンタルサーバーの契約をして、ムームドメインでドメインを取得。20年ぐらい続いている。
費用(今日時点)
ドメイン:税込2318円(一年)
レンタルサーバー:330円(一ヶ月)
ざっくり毎月500円ちょっと。
ブログサービス、各種プラットフォームをうまく利用すれば無料でまかなえるけど、XやFacebookのタイムラインそれでいいの？とか、自分で投稿したテキストをエクスポートできないって？とか、もろもろ制約も多いことだと思う。
その点、毎月500円程度、追加なしの牛丼一杯ぐらいのお値段で、ホームページ、ブログ、SNS、web本棚とインターネットで自分の好き放題に使えて遊べる居場所を確保できるんだから安いんじゃないかな。
以下、公開してる個人サイトを古い順に。
【ブログ】
『ひまつぶし雑記帖』1998〜
このブログ。
これはレンタルサーバー以前、最初はプロバイダのホームページ「public_html」以下のURLに「~」がつく「ニョロホームページ」でスタート。HTMLを書いてFTPでアップロードしてたのをperlによるCGIにリニューアル。さらにレンタルサーバーに移って今のいわゆるブログ形式にした。
ブラウザで管理画面を開いてテキストエリアに入力、画像のアップロードやカテゴリ付けも同じ画面で完結する。
ブログとはなんぞや、みたいな話は知らないけど、CMS(？)のお手軽さはいいよねえ。
小学校の頃の日記なんか、それこそ三日坊主だったのは書くことがないのもそうだけど、日記を書くための準備が面倒くさかったから。
今だと毎日パソコンを立ちあげてごそごそしてるわけで、「ついでに」ブログ(雑記・日記)を書く動線が目の前にある。
エントリの内容は…基本ヨタ・ネタ・譫言がほとんどだけど、ライフログとかいうそれっぽい言い方もあることだし自分的にはギリOK、かなぁ。さすがに20年前ぐらいは昭和平成で、21世紀の今からするとアウトのものが多いけど「発表当時の世相を反映しております」てことで。
【web本棚】
『趣味は読書2』2006〜
本棚共有サイトとして2006年にサービス公開。わたしの年齢的なこともあり、継続するのも限界が近いので新規登録を終了。レンタルサーバーの契約更新のタイミングで終了の予定。登録ユーザーさん向けに各自の本棚を復元するスクリプトを作って案内した。
『web本棚』2026〜
上記の『趣味は読書2』で作った復元スクリプトで自分のweb本棚を公開した。
この本棚は、本をダブって買うことのないようにチェックするため、というのがスタート。いまや電子書籍になって「購入履歴」で確認できるので役割終了。さらに電子書籍は付箋やメモもつけられて便利な機能が満載だし…と思いつつ、自分の使い勝手で機能をつけてきて馴染んでる、使いやすい。
それに、本棚って、眺めるだけで楽しくなるのはわたしだけじゃないと思う。
老眼がすすんで文庫本の小さな文字サイズがつらくて読書量も激減してるんだけど、つい先日、老眼鏡を作ったのでふたたびみたびこの本棚の出番となった。
ActivityPubを喋ってフェディバース経由で自分の本棚を検索できるようにしたので、自分専属の司書さんみたいなもの。
ホームページの方にソース公開
『web本棚のソースコード::On Golden Pond』
https://www.doncha.net/monooki/bookshelf.html
『web本棚ActivityPub対応部分のソースコード::On Golden Pond』
https://www.doncha.net/monooki/bookshelf-activitypub.html
【SNS】
『ため池::ところてん』2023〜
https://tokoroten.doncha.net/t2aki
X(旧ツイッター)がごちゃごちゃになった2023年ごろ、(わたし的には)27歳で猫が亡くなったことも重なり、時間もぽっかり空いたので、SNS環境を変えようとActivityPubの実装をした。
それまで登録していたX、Facebook、instagram、mixiから撤退。アカウントをすべて鍵アカにして塩漬け(blueskyやmixi2にも登録したけど、これらも結局塩漬け)
タイムラインが時系列になってるだけで、なんの意図も恣意もないものは、XやFacebookなんかとはまったく別もの。って、元ツイッターがそうだったんだけどねー。
居心地がいいので入り浸り。
ActivityPubの実装についてホームページで随時公開
『おひとり様ActivityPubサーバーの自作実装::On Golden Pond』
https://www.doncha.net/activitypub.html
【ホームページ】
『On Golden Pond』2024〜
ブログ『ひまつぶし雑記帖』はもともと日本語の文章、テキストを流しこむことが大前提。
なので、perlのスクリプトやcssなんかを表示させるのに向いてない。すべてのエントリでレイアウトデザインも同じになる。って、当然。
biglobeやinfoseekで「ホームページ」を作ってた頃のように、素のHTMLを書いた静的ページをFTPでアップロードする「ホームページ」を作りたくなった。
ペラ1枚で表示もちょっ早だし「HTMLをそのまま」なのでページはなんでもありの自由を満喫できる。実際作ってみてそこが面白い。
ヘッダ部分など、訪問するひとには見えない・関係のないところはスクリプトでつけるようにオレオレMovableTypeにしたけど、本文はエディタで書いていく。
ページを作るのが面白い・楽しい。
『20世紀型個人ホームページの効能::On Golden Pond』
https://www.doncha.net/favorite/20241201-adventcalendar.html
以上が今のわたしのインターネット生活。というか自給自足の自作自演生活。
ごちゃごちゃ書いておいて実際のとこ、それどうなの？というと個人サイトはほとんど見られない。
ホームページはbot、crawlerを除く「人間のアクセス」は一日一桁程度。
ブログも似たようなもんだけど、こちらは25年ぐらいやっていてページのボリュームがある分、ホームページよりはマシ。EPUB3電子書籍がらみのエントリは今でもそこそこアクセスがある。とはいえ、アクセスの多いエントリでもせいぜいふた桁だけど。
個人ホームページは自分が満足できればそれでOKという納得がなければやってられない。
個人ブログは、今だったらnoteなどのひと通りの多いプラットフォームを利用する方が確実に読まれる。個人でブログをやるのはやっぱり自分のため。
といった大きなデメリットがあるんだけど、全部が自分のもので自分の好き放題になるというメリットには敵わないと思う。
あと。無職還暦爺いの趣味としては金もかからなくてお手軽気楽なのがいいですよね。全部perlで自作実装なので呆け防止になるし。
ブログの一番の読者は自分
ブログをリニューアルしたものの、データベースから作り直したもんで、カテゴリなどリレーショナルなところを更地にしてしまった。
てことで、カテゴリのつけ直し。
旧ブログでついてたカテゴリはそのまま…て、ほとんど使えず、ひとつずつエントリをざっと読んでカテゴリづけとなった。
そこにはスクリプトを書いてる時の高揚感などどこにもなく、昔の自分のどうでもいい話につきあう、という地味で陰気な作業。スクリプトを書いてる時より、こっちの作業のほうが圧倒的に時間がかかった。
結局、カテゴリ再設定に一週間近くかかってビックリ。
このブログ、というか、日記/雑記は1998年からつけていて、昔はSNSなどなかったもんだから、1記事、1エントリになにかテーマをもって書いた、なんてことはなくただただ何かの垂れ流し。カテゴリもくそもない。
そんなぐっちゃぐちゃのカテゴリづけ。
特に2004〜2006年ぐらいのエントリは、読み返してみるとシュールでカオス。新卒で入社した底辺エロ出版社を20年勤めて退職。職安に行っては面接の繰り返し。90年代後半にバブルが崩壊、その影響もあって買い手市場。
堅い出版物の某社に行ったらば、秘書か役員か愛人らしき年配の女性と、おれの前でイエス以外の返事はすんなよこのチンピラという威圧感たっぷりの多分ラスボスらしき年配の入道。
「あら凄いわねえ、こういうのいいの？」と持って行ったメガドリームを一蹴され、「柔らかいところだと朝も緩いだろ、うちは９時だからきついぞ」と。まるで性犯罪者か朝もまともに起きられないダメ人間扱い。とほほ。
なんてのや、
メシのためとはいえよくこんなのやってましたね、とか、いまさら会社に入っても馴染めないでしょひとりでやればどうですか、とか。
こんなエントリばっか。
(※メガドリームというのは最後にわたしが作ってたエロ漫画＆小説雑誌)
とはいえ。
よくまあ、わたしも企業もこんなでやってたなあ、と昭和回顧の走馬灯だ。無事に今まで生きてこれたことに感謝。
ついつい、昔のどうでもいい自分のどうでもいいエントリを読んでしまってた。そりゃカテゴリづけに一週間もかかるわけで。
作家さんじゃないけど、自分の書く・描く小説・漫画の第一読者は自分で、想定する最初の読者も自分ということだなあ。
自分以外のひとが読んでも面白くもない日常が、たぶんブログ。
関連エントリや、直近のエントリ、カレンダーのリンクなんかを設置してるけど、読むのは自分だけだろう。逆に言うと(？)自分のためにあるからこそ続けられるんだよね
ブログをレスポンシブ対応にリニューアル
今回のエントリはタイトル通り、ブログをレスポシブ対応にリニューアルした!
このブログ、ひまつぶし雑記帖は前回のエントリに書いたように、もはや前世紀の遺物。
いちおう、スマホ対応はしてたとはいえ、UserAgentを見ていろいろ振り分け。このUAを見るというのは、どうやらそろそろ限界らしいという噂がここ何年も続いてた。
今どきのレスポンシブ対応にしておかないとまずいなあ、と思ってたんだけど気が重くて放置状態だった。
最近、個人ブログを読むのが楽しくなってきていて
↑こちらからいろんなひとのブログを訪問してる。
みなさん、情報も適当適切だし、レスポンシブだし、それと比べるとウチはとっちらかってるし…というのを思い知らされたり。
てことで、ブログを作り直すことにした。
レスポンシブ対応が一番だけど、20年ものだしあちこちガタガタ。
特にデータベースは、ド素人。スクリプトを見るとalter table addなんちゃらがあちこちにあってのけぞる。
とはいえ、素人なりにいろいろ考えてたらしい自分はちょっと頑張ってたかも。
最初は新しく作って過去の遺物は廃棄、と思ってたんだけど、昔の自分に止められて過去分を引き継いでリニューアルということにした。
今は亡きツイッターだのfacebook、mixi対応までしていてスクリプトのあちこちに産廃、ガレキの山もあって、これらも掃除するいい機会だ。
データベースを新規に作ると、今までのURLにも影響する。
SEOというやつがもはや意味をなさないらしいんで、気にすることもない。ただ、リンクを貼られてるエントリもあるんで、対応は必要。
rewrite ruleでやると、身動きできなくなることも考えられるんで、スクリプトに仕込み。
久しぶりにSQLを書いたのは、ボケ防止になったかも。perlは相変わらず面白いし。
30年ぐらい前にLibrettoを自宅サーバーにして公開してたこともあったなあ
ブログのふり返り
この雑記帖の見直しというか、ふり返りが今回のエントリ。
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歳だしブログで頑張るのも限界だろうから、テキトーな与太も書き散らかして終活としよう。
何度も書いてるけど。歳くったら
「身の回り半径50cm、前後5分」
ぐらいが、ちょうどいい塩梅ってやつだよなあ
小ネタ：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系のパッケージは本体署名に対応してないんだけど、むしろこっちの方が合理的かもしれない。
様子見するけど、これって対応する必要がないと思ったなあ。どうなんだろ…
