HTTP Signatureをlolipopレンタルサーバーで作成
ActivityPubでPOSTするには電子署名が必要。
というエントリを書いたけど、WEBでサーバー同士でやりとりしたり、WEBサービスのAPIを利用したり、電子署名が必要なのはActivityPubに限らず。
ちらほら書いてきたように、lolipopレンタルサーバーにはperlで電子署名をする時によく使われるモジュール「Crypt::OpenSSL::RSA」がインストールされていない。
ということは。lolipopではHTTP Signatureを作ることができない「Cryptが使えないんじゃ話にならない」ということになる。
しょうがないんで、ローカルにcpanから「Crypt::OpenSSL::RSA」をインストールして、ActivityPubにPOSTする時はローカルのスクリプトを使う、という急場しのぎ。
これはこれで、投稿するのにひと手間あった方が事故も起こさなくていいかな、と思ってやってたんだけど、やっぱりサーバー上だけでやれるならラクちんなことは確か。
なもんで、グーグル先生にお願いしてみたら
「Crypt-Perl-0.38」https://metacpan.org/pod/Crypt::Perl
↑pure perlのCryptモジュールがあった。
インストール時にコンパイルが必要なモジュールはOSやファイル構成、環境に依存するけど、PurePerlというのはperlだけで作られているので、perlさえあればサーバーにそのままアップロードして使える。
さっそくダウンロードして展開。テストスクリプトで試したところ、依存関係で必要なモジュールがあったのでそいつらもダウンロードして展開。
Class-Accessor-0.51
Bytes-Random-Secure-Tiny-1.011
Convert-ASN1-0.34
Crypt-Format-0.12
（あと、たぶん以前amazonのAPIがらみでインストール済みのpure perlのDigest::SHAも必要）
当然ながら（？）これらのモジュールもpure perlなので、コンパイル不要、展開するだけで使える。
サーバーの適当なところ、例えば「lib」というディレクトリを作って展開したファイル群をアップロードするだけ。
lib/Bytes/
lib/Class/
lib/Convert/
lib/Crypt/
スクリプトで use lib 'lib'
などとやればlolipopレンタルサーバーでもCrypt RSAが使えるようになる。
いや。ぶっちゃけ。これらモジュールの作者のみなさんには大感謝。大袈裟じゃなく狂喜乱舞小躍りだった。ほんとうにありがとうございます。
マジperl使いすげー。perl話者が減ってるだろう昨今、凄腕のperl使いはワシントン条約で保護すべき存在。
使い方は「 RSAモジュールで公開鍵と秘密鍵 」とほぼ同じ。
秘密鍵を使う
my $privatekey = Crypt::Perl::RSA::Parse::private($private-pem);
公開鍵を使う
my $publickey = Crypt::Perl::RSA::Parse::public($public-pem);
Signatureを作る。
my $sign = $privatekey->sign_RS256($sign-str);
encode_base64($sign, "");
Signatureを検証する。
my $decoded = decode_base64($sign);
$publickey->verify_RS256($sign-str, $decoded);
あとは。
こうすると、思いつきから投稿放流までが直結するので、事故を起こさない自制心が必要となるです、はい。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» API(30) » perl(124) » web(174) » ActivityPub(10)
ActivityPubサーバの終わらせ方
おひとり様ActivityPubサーバーというか、最低限のオレオレAPサーバーを立ち上げた、のはいいけど、これの終わらせ方も調べないとダメ。
どんなアプリも起動方法と終了方法はマニュアルに必須の情報。
もうこのサーバーは終了しましたというお知らせを出せばいい、とのこと。
サーバー（サイト）へのアクセスに対して
「410 gone」（もう存在しません）を返す。
.htaccess
RewriteEngine On
RewriteRule .* - [G]
これで、サーバー（サイト）は終了しました、というお知らせになる。
いつまでこのお知らせを出せばいいのか。
特に決まりごとはない。
原則、サイトがある限りこの状態にすればいいということだけど。
このサイトはもう存在しませんよ、というのが周知されればOK…いや、周知されたかどうか知る方法はない。なので、根拠なく数ヶ月ぐらいでいいんじゃないか、とも言われている。
DNSの反映にしてもすべて行き渡るのにどのぐらいかかるのか知るよしもなしで、ネットがからむといきなり運任せというか神さまだけが知っている、という状態なのがメタな話で閑話休題（それはさておき）
サーバーのドメインを維持し続けるならともかく、サーバーもドメインも削除することもあるだろうし、その場合はその削除までのお知らせ掲載期間として数ヶ月もあればいいということかな。
サーバー（サイト）終了のお知らせが必要な理由は。
おひとり様APサーバーといっても、Fediverseに繋がることになる。
一度なんらかのアクションを起こすと、おひとり様APサーバーが、他のサーバーからリクエスト先として認識される。そうすると投稿やフォローはもちろん、各種Activityのために他のサーバーはリクエストを飛ばしてくる。
ところが、サーバー（サイト）をお知らせなしに終わらせると。
他のサーバーは存在しないサーバーがメンテで落ちてるのか本当になくなってるのかわからない。しょうがないんで、リクエストを再送しようとする。これが負荷になる。ネット全体に悪影響となる大きな負荷ではないんだろうけど、それでもチリツモ。
なので、ちゃんと終了のお知らせ掲載は必要。
どれだけの数のサーバーに繋がるのかは、それこそ神のみぞ知る領域。気軽手軽におひとり様APサーバーだっ！とか言ってもひとはひとりで生きるわけじゃない、とも。ActivityPubで繋がることの魅力でもあるし、そこに生じる責任とか、やらなければならないことの自覚も促されるところ、だ。
わたしみたいにミーハーな勢いだけでおひとり様オレオレAPサーバーとか言ってはしゃぐだけじゃダメです（自戒）
始めたものを終わらせる準備はしておく。
お盆だしね。
参考にさせていただいたサイト。
いつかサーバーを閉じるとき 〜お金をかけずに 410 を返す方法〜
あまり手間も費用もかけずに410 Goneを返してみる
RewriteRule Flags
サイトを完全に削除する方法
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
夏風邪
相変わらず、というかコロナの感染状況が酷いことになっている今日このごろ。体調不良で転がっていた。
8/3ぐらいから喉のイガイガと咳が始まり、8/8夜ぐらいから熱が出始めて、咳き込むと喉に焼けるような痛み。
去年コロナに罹患した時と症状はそっくり。その時と比べると。
喉の痛みは焼けるような感じだけで外傷で掻きむしられるような感じはなくなって、熱は38度弱から37.5前後と、レベルは下がった体感。
そもそも7/27にワクチン接種したばかり。まさかなあ、と思いながらも熱が37.5ぐらいまで上がると、身体がかなり「しんどい」
8/10にかかりつけ医に電話して診察してもらった。
体調不良を訴える患者さんは11:00から受付で15分刻み。対コロナ完全防備の看護師さんに酸素濃度や血圧など測られつつ問診票に記入後診察となる。
コロナとインフルの検査は陰性。葛根湯、痰を抑える薬、炎症を抑える薬、頓服のカロナールを処方されて終了。待合室を見ると患者さんがひっきりなしだった。
薬局の外から電話を入れて薬を出してもらって帰宅後薬の服用を始めた。けど、熱が下がらずしんどい。カロナールは38度ぐらいになったら使ってね、と薬剤師さんだったけど、痛いのとかつらいのには人一倍弱いので、とりあずカロナールを1錠だけ。
さすがに熱が少し下がってラクになった。
だけど8/11は相変わらず。熱が出てしんどいし、咳き込むと喉の痛みも酷い状態が続く。
抗原検査の精度は落ちるという話もあり。先生も気になるようだったらPCR検査しますけど、時間もかかるし、症状が出てから時間も経ってるので仮にコロナだとしても収束する時期、ということで昨日はスルー。
とはいえ、休むと連絡したらくそシフト仕事のリーダーから再検査するようにとSMSが飛んできてるし、しんどいのは続いてるので再検査をすることにした。自分の感覚でもコロナ濃厚だったし。
前回コロナの検査をしてもらった近くの発熱外来もある医者で8/12 12:30からの枠が空いてたので予約。ここはかかりつけと違って新しくできたところでしっかりネット対応。アプリまである。
ところが行ってみると廊下のパイプ椅子までいっぱいに埋まっている混み具合。実際に検査室に入ったのは13:15ぐらいだった。
検査となって抗原検査にします？PCR検査にします？と。あれ？時間がかかるんじゃなかったけ、と思ったけど15分ほどで結果は出るらしいんで、PCR検査をお願いした。さすがは発熱外来というところかな。
結果。こちらも陰性。
抗原検査でも別の日のPCR検査でも陰性となれば、さすがにコロナを疑うわけにもいかない。今日は熱も平熱まで下がっていて、身体がずいぶんラクになったということもあって、夏風邪ということで落ち着いた。
エアコンで肌寒く感じたり、焼き殺されるような陽射しにくらくらしたり、寒暖差のストレスに身体が負けたな。老人にはついていけない。
にしても、コロナが酷いな。
病院ふたつに行って、目撃したことに改めてビックリさせられた。どちらも患者さんが行列待機状態じゃないか。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
映画『海街diary』
アマプラでなんとなく観始めた『海街diary』がびっくり。目が離せず、じんわり染み込んできて涙腺がいたるところで決壊してしまった。
派手な事件、出来事は何もないのに画面に釘付け。丁寧な人と人の距離感がめちゃくちゃ優しくてじわじわ涙腺に迫ってくる。役者も全員キャラ立ち。綾瀬はるか、長澤まさみ、夏帆、広瀬すずの目の高さが揃ってる。どの目線も、とにかく優しい、のひと言。
画面の絵面も優しさに溢れている。
伏線も細かい。
事件らしい事件も起こらない、家族の日常。少しずつ重なるキャラたちの背景。それだけ。家族は物語になるんだなあ。ていうかどんな出来事も事件てことか。
半村良の葛飾物語も同じく。法要の度に集まる親族のエピソード。これも事件らしい事件も起こらない。親族、各家族の近況報告。
これもしみじみ泣ける。
もちろん。家族だけど、血の繋がりは関係ない。海街diaryは異母妹を引き取って家族になる話だ。
共同体というのともビミョーに言葉のニュアンスが違うと思っていて。だからといって父母がいて血の繋がりのあることが前提とも違う。
一緒に過ごした時間だけじゃなくて、一緒に過ごさなかった時間も共有できるひとたち。
家族、疑似家族ものには、わたしの涙腺は抵抗力がないんだ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
ツイッター後のSNS事情
ツイッターが亡くなったんで、あちこち模索しつつ、今までのほかのSNSも整理整頓。
いや、お前のSNS事情など知ったこっちゃない、というのはもっともだけど、ここはわたしのあんなことやこんなことの垂れ流しの場所なので、知ったこっちゃないのは承知のネタ。今回はほんとただの備忘録。
まず最初に、Facebookとinstgramはアプリ削除。
もともと、ザッカーバーグというやつのソフビ人形みたいな顔が気に入らないのはともかく、メタのやってるSNSは、フィードの表示基準がまったく理解できなくて論外。なんで今、その投稿が最初に表示されてる？とか、マッチングで表示するとかいってる広告もハゲだの大人の出会いだの、いくらなんでもクソすぎて見るに堪えない。
ハゲは病気じゃないし恥じることでもない（ちょっとかっこ悪いだけだろ）大人の出会いってシモの世話も視野に入ってくる還暦はそっちのシモの話じゃない。
まあ、ありていにいってfacebookもinstagramもクソ。
facebookはリアル知人たちがいる、instagramは亡くなったみけさんの写真だらけ、ということでアカウント削除まではできないんで、アプリ削除で勘弁してやる。
さて、Xこと元ツイッターだ。
（旧）ツイッターのAPIを使って公開しているWEBサービスについては、サービス終了や一部機能の停止をアナウンスしたのでこっち側の手当はした、つもり（ずいぶんいろいろなところでツイッターのAPIを利用してたなあ…）
なので、ツイッターを使い続けるメリットはもはやどこにもない。
…メリットはないんだけど、わたしが見たいアカウント、ツイッターでしか見ることができないアカウントがいる。具体的には、猫アカウントのひとたちなんだけど、わたしが見てるひとたちは、本当に猫が好きだし、猫との距離感もいい感じだし、いちいちコメントも頷けることばかり。
なので、Xについては、アプリ削除すると困る。
非公開リストを作って、猫アカウントのひとたちを登録。Xにログインしたらそのリストを見る、だけにする。
ちなみにリストの名前は「twitter」にした。
（こっちは、かなりイケてる猫アカウントばかりを厳選してるので、興味のあるひとがいたら連絡ください。こっそり共有します）
そして「ツイッター後」の今日時点でいうと。
Mastodonに軸を移した。
この雑記帖でもここんとこのネタはActivityPubばかりなのはそのへんのことがあったから。
ザッカーバーグやマスクのところに依存することがない、誰かやどこかに依存することのないFediverse、連合空間に魅力があったから。
今のところ、以下の４つのサーバーにアカウントがある。
https://bookwor.ms
https://fedibird.com
https://himagine.club
https://mstdn.jp
2017年、6年ぐらい前に登録してる「本の虫」https://bookwor.ms 以外はつい最近。ActivityPubのテストも兼ねて登録したところ。どのサーバーもオススメできると思う。
この中で一番（旧）ツイッターっぽいところは「fedibird」かな。
「himagine」はちょっとオタク臭が強いので、わたしは平気だけど、抵抗のあるひともいるかもしれない。
「mstdn」は登録者数も多くてそのボリュームがいいところだろうと思いつつ、おひとり様APサーバーのテストでしか使ってないので、ここの傾向と対策は不明、だ。
で、Mastodonというかそっち系は、Facebookやtwitterとは違って、複数のサーバーの集まった連合集団。
１つのアプリで見るものを共有できる、というものではないのがボトルネックになる。
PCのブラウザで見ればいいんだろうけど、SNSの利用状況は、スマホファースト。となったときに、スマホでブラウザで、というのは老眼老人には厳しいんで、アプリを探すんだけど決定打がない。オススメされたアプリで見たんだけど、たぶんサーバーごとに実装が違うところがあって、同じ操作で同じ表示になっていないっぽい。
ひらたく例を探すと。
医者の待合室。おばあさん、おじいさんたちが、テレビのニュースやワイドショーにいちいち頷き、ツッコミを入れながら知り合いのおじいさん、おばあさんとあれはねえとか共有する世界があって、（旧）ツイッターはそこにちゃんとあったんだけど、今のツイッターもマストドンも、あっちこっちのテレビの言うことが違うんで、そんなん聞いてへんで、という齟齬がでてくる、ということになってる。てな感じかな。
そのあたりの状況をちょっと把握する必要があるかもだけど、Mastodon系はツイッター後のSNSとしては面白いんじゃないかと思ってる。
で、んなことを踏まえつつ。
そのマストドンと繋がるおひとり様サーバーというかオレオレサーバーも最低限のActivityPubを実装できたんで、SNSはマストドンだけでいいんじゃないかという今日このごろです。はい。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
最低限お一人様ActivityPubサーバーにちょい足し
ActivityPubを話すことで、Fediverse連合空間からアカウントとして認識されて、FollwやFollow受付、Noteの投稿ができるようにした。
最低限実装のお一人様サーバーなのでいろいろ手抜き。
フォロワー管理もそのうちのひとつ。followersへのアクセスに対して中身はからっぽで、ステータス200を返すだけでも特に問題はないということだし、何も用意せずただ200 OKを返してた。
実際、アカウントもサーバーも認識されたので、followers.jsonはなくても問題はない。
だけど。
「各 actor は followers コレクションを 持つべきである(SHOULD)」
W3C Recommendation
ということなので、それなりのものを用意しておいた方が良さそう。
mastodonもmisskey系もサーバーで共有のinbox、ビル入口の郵便受けみたいなものを持っていてそこに届いた郵便物をビル内の各人に配送するための仕組みとして、こちらのfollowers.jsonを利用してることが多いらしい。
つまり、followers.jsonを用意しておけば、こちらは相手の入ってるビル宛にだけ投稿をPOSTすればOKということ。
ビルの宛先はフォロワー情報の中のshared_inboxのURL。
ここに送ると受け取ったサーバーは、こちらのフォロワー情報をみて、サーバー内のフォロワーのinboxに配達してくれることになっている。
今のところ、これについてはActivityPubの決まり事ではない。mastodonやmisskeyなどは対応してくれているらしいが、サーバーごとで対応が違うので現物合わせ、というか確認しながら試しながら、実装するのがよさそう。
followersの記述はシンプル。
{"@context": "https://www.w3.org/ns/activitystreams",
"id" : "https://example.com/actor/followers",
"type": "OrderedCollection",
"totalItems": 5,
"orderedItems": ["https://hoo.jp/users/foo",〜]}
id,type(OrderdCollectionがMUST)、フォロワーの数、フォロワーのURLの配列。
これだけなので、フォロワーが1000人10000人もいるならともかく、10人程度なら手作業で作って用意してもいいんじゃないかな。
以上の元ネタは
https://fedibird.com/ の管理人、のえるさん（@noellabo@fedibird.com）情報
送る相手の情報に、inboxの他にshared_inboxがある場合があります。というか、MastodonやMisskeyなら必ずあります。
同じサーバに所属するフォロワーは同じshared_inboxになるので、これでまとめると、一つのサーバに対しては一回だけPOSTすれば良くなります。これによりかなり効率化されています。
宛先自体は、ToないしCcに送り元アカウントのfollowersコレクションを指定すれば、受け取ったサーバ側でそれぞれに配送してくれます。
shared_inboxがない場合は、それぞれのinboxにPOSTします。
いずれの場合も、同じIDのCreate、同じIDのNoteであれば、受け側が重複排除するので、何度も送っても大丈夫です。
フォロワーの数だけリクエストを飛ばす＝マルチポストの迷惑サイトになったらまずいなあ、と心配だったのでfedibirdでそのことを投稿したら返事をいただけたもの。ありがとうございました！
AIに郵便配達を描いてもらったんだけど、なかなかうまく意図が伝わらず、かろうじてこの1枚。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» perl(124) » web(174) » ActivityPub(10)
