映画『海街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」
非中央集権型SNSがオススメ
ポケモンGOも開かず、スクリプト書き、調べものばかりのほぼ2週間だった。
ウチにいる時間のほとんどを使った、と思う。
その結果、ActivityPubを通じてFediverse連合空間に参加することができた。
その連合って、なんのこっちゃだけど。マストドン（Mastodon）やmisskey、といった非中央集権型SNSサーバーというやつで。ツイッターやfacebookみたいに私企業が公開提供するひとつのサーバーに集まるのではなくて、あちこちに散らばるサーバーがあってそれらがActivityPubという共通の言葉を使って繋がるというもの。
中央集権型（ツイッター、Facebook)に対する非中央集権型（Mastodon、misskey）という図式。
独裁国家vsパルチザンとか、米帝vsベトコンとかそんなもん（違
インターネッツのまだ普及していない昭和の頃でいうと、PC-VAN、日経MIX、Nifty-serveがパソコン通信の代表。それに対して個人レベルの草の根BBSみたいなものもそれなりに立ち上がっていた。という状況にふたたびだかみたびだかになるかもしれないなあ、と。
電話がご町内に一台、一家に一台だった時代から、いまや、家族全員ひとりに一台ケータイを持つ時代になってるし、個人がひとりサーバーを持ってネットワークに繋がる時代とかになったら面白いかもしれない。
中央集権型サーバーだと体制側の恣意的なコントロール下に置かれるのに対して、非中央集権サーバー群の場合はコントロールが効かない。アナーキーでファンキー、グルービーでカオスな状況になる。
なんかすげー死語だらけの戯言だけど、昭和なもんで勘弁してください。
てなジジイのヨタはともかく、ActivityPubの実装は面白くって、それで調べてたMastodonなんかはどこかのサーバーに参加することをオススメ。
https://mstdn.jp/
↑最初は最大手っぽいココあたりから。
ツイッターもフェイスブックも最初の頃は誰しも使い勝手がわからず苛ついたことがあったと思う。Mastodonも最初は使い勝手が違うんで苛つくと思うけど、そこを乗り越えればけっこう居心地はいいんじゃないかな。
超初心者向けMastodonガイド
https://prgm.x0.com/mstdn/
↑こちらの解説がわかりやすい。
ところで、なんでお前はActivityPubとかわけわからんことやってるの？それって何かなるわけ？金になるの？と言われると困るんだけど。
面白いから、としか言えない。
Webhook的に ActivityPub に投稿する実装を作った
オープンな仕様 ActivityPub の力を借りて自前実装で他の実装とつながれる体験は心躍るものがあり
↑200%同意。首肯1000回。
その時には何にもならないことも、いつか何かになるというのは仙人に弟子入りのテンプレ。人生に無駄な時間など1秒もない…んだけど、そろそろ終いを考えなきゃいけない歳だから、あまり偉そうなことを言う時間などない。
詠人不知。
ちなみに。
https://t2aki.doncha.net/?cat=64
↑最小限のActivityPubを喋るサイトの作り方はこちら
素人なりに真面目に調べて書いたので、それっぽい情報になってると思う。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
ActivityPubにおそるおそる話しかけてみた
ActivityPubを通じてフォローしたり投稿したりするには避けて通れないRSAの署名、というかサインというか。
これ絡みが、もう本当に五里霧中で迷走するばかり。
いろいろ検索しまくってこれでイケるかも？ぐらいのところまで来たので、いったんメモ。
RSAモジュールで公開鍵と秘密鍵
↑鍵を作ってサインする方法は前回のこれで正解。
一番の問題は、サインを作る対象となる文字列をどうするの、というところ。これはなんでもいいんだけど、ActivityPubに通すので、そっちに合わせる必要がある。
結論からいうと必要な材料は以下。
・リクエストのメソッド（POSTとかGET)とリクエストするURI
・相手側のホスト名
・日付、
・本文のDigest
mastodonの仕様だと必須なのは、日付とdigestの2つなんだけど、実際にmastodonから飛んでくるリクエストのログを見ると、この４つが必ず入っている。
オマケでcontent-typeやacceptを入れることもある、らしい。
具体例をあげると
(request-target) POST /actor/inbox
host: example.com
date: Wed, 26 Jul 2023 02:00:32 GMT
digest: SHA-256=unkTWZOjiNdJT4SDuAU6tCy6A0QM0PZ2bs0353xOt+k=
content-type: application/activity+json
「キー 区切り 値」の並び
host「:」「半角空白」example.com
という形式で、キーはすべてアルファベットの小文字。
(request-target)だけはコロンは不要
これら、ひとつひとつを「改行」で繋げて並べた文字列を対象としてサインすることになる。
digestというのは
元データから、ハッシュ関数と呼ばれるあらかじめ定められた計算手順により求められた値です。 ダイジェスト値とも呼ばれます。 ハッシュ値を求めるハッシュ関数(※)には、元データが1ビットでも異なれば大きく異なるハッシュ値が生成される（同じハッシュ値になることが実用上ない）方式が選ばれます。
perlだと「MIME::Base64」のencode_base64という関数をそのまま利用。
encode_base64(本文,"")と、2番めの引数に空を渡さないとDigestに改行がついてくるので注意。
本文というのはfollowやcreateといったActivityPubで使うjson文字列。
対象文字列が決まったら、RSAで署名して、リクエストのヘッダに入れる。
'host' => 'example.com',
'date' => 'Wed, 26 Jul 2023 03:52:07 GMT',
'digest' => 'SHA-256=unkTWZOjiNdJT4SDuAU6tCy6A0QM0PZ2bs0353xOt+k=',
'content-type' => 'application/activity+json',
'signature' => 'keyId="https://tokoroten.doncha.net/t2aki#main-key",algorithm="rsa-sha256",headers="(request-target) host date digest content-type",signature="qCEXfTo~略~I9zfRqcUaTwjew=="',
↑これはperlのlwpを使ってヘッダに設定している部分。
Signatureの
keyIdは「actor.json」に入れた公開鍵のkeyId
algorithmは暗号化の方法「rsa-sha256」
↓適宜改行は入れたけど、こんなリクエストを飛ばす
HTTP_DATE :: Tue, 25 Jul 2023 23:55:38 GMT
HTTP_DIGEST :: SHA-256=giwfKVIT61lc9LpR7EsgEJBmHilheDpPwFnqdjMBjrA=
HTTP_HOST :: example.com
HTTP_SIGNATURE :: keyId="https://tokoroten.doncha.net/t2aki#main-key",
algorithm="rsa-sha256",
headers="(request-target) host date digest content-type",
signature="SE〜略〜JEVPj9
サインの検証は問題ないし、リクエストもこれで問題ない、と思ったんだけど、mastodonだと401で弾かれる。firefishだと202でどうやら受け付けてもらえるっぽい。
同じリクエストを送ってるのになんでこっちはダメでこっちがOKなのか理解できていないのが現状。
その他ハマったところ。
公開鍵って改行されてるけど、actor.jsonのpublicKeyPemに入れるのにどーすんの問題。
jsonは改行入りデータは扱えない。ただただ改行を削除して一行にすればいいんだろ、ぐらいに思ってたんだけど、検索して眺めてると「バックスラッシュ」「n」という2文字の文字列になってるっぽい。これ、改行なのか2文字の文字列のことなのかわけわからず、ほぼ1日弱経過。
perlのJSONでencode_jsonしてみりゃいいことに気づいてやってみたら、2文字の文字列に置換されていた…改行を「バックスラッシュ」「n」の2文字の文字列て、なんか不細工じゃね。
(request-target)ってなんやねん問題。
どのリクエストのヘッダもこれが先頭にあったんで、てっきり、これに続く要素を要求しますよ、という宣言みたいなもんだと思ってたら大きな間違い。こいつもキーのひとつだった。
HTTPメッセージに署名をするSignatureヘッダの標準化
Digestの生成を疑った問題。
リクエストが401で弾かれっぱなしだったんで、どこが問題だろうと。HOSTやDateは目で見てわかる文字列で、そこは大丈夫だったので、Digestが違ってるわけ？と。
perlのDigest::SHA qw(sha256) MIME::Base64 encode_base64(sha256($content),"")で作ったDigestの検証。
コマンドラインで
cat accept.json | head -c -1 | sha256sum | xxd -r -p | base64
などとやって差分のないことを確認。Digestも問題なかった、やっぱり1日弱経過。
実際、まだマストドンからは401で弾かれるので、何か間違えてるはず。
とはいえ、 himagine.club (firefish)から202が返ってきたを見てめっちゃ嬉しかったので、ここらでひと段落とするかなあ。これ以上やったらただでさえマダラハゲなのに禿頭一直線になりそうで怖い。
mastodonのSignatureのソースコード
"#{Request::REQUEST_TARGET}: #{request.method.downcase} #{request.path}"
ActivityPubに対するSignatureのPHPのソースコード
'(request-target) %s %s%s'
あれ？(request-target)の後ろにコロンがいるのかいらないのかよくわからないぞ。コロン一つでverifyの結果が違う…て、どっちでやっても401だったけどな。
[07/27 19:52:17] うまく開通したスクリプトではコロンをつけた文字列。
[07/26 16:29:44] 追記
をっと。202が返ってきても繋がったわけじゃなかった。まだどことも繋がらないってこと。どこが違うんだろ。401じゃないってことはヘッダやサインは問題ない、という理解でいいのかな。これは根が深い。お手上げ、かなあ。
[07/27 11:21:59] 追記
開通！というかActivityPubを通じてFediverse連合空間に入ってfollowもpostもできた！
401の原因。
actor.jsonに記載のpublicKeyPemの始まりのハイフンがコピペミスでひとつ足りなかった。5つ必要なのに4つしかなかった…だけだった。
我ながら雑で阿呆なミスに愕然し、驚愕するばかり。
とはいえ、この何日か、けっこう必死こいて調べまくったので、SignatureやHTTPヘッダについて改めて知ったこともあったので、結果オーライ。
副産物というかverifyするスクリプトやログを片っ端から取るスクリプトを作ったのも今後役に立つだろうと思うし。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
リアルタイムWEB
ツイッターのサービス開始が2006年ということだから、その頃に話題になった言葉が「リアルタイムWEB」。2010年頃の「アラブの春」は確かFacebookの拡散力があったからとかないとか。
拡散力もそうだけど、その「リアルタイム」、文字通り「即時性」というか「刹那的」なのがわたし的ポイントだった、かな。
時系列で流される投稿は目の前のタイムライン、フィードからすぐに流れて雲散霧消。自分の投稿も他人の投稿も時間がたてば流れていくだけ。
自分がタイムラインを覗いた「その時その場」がすべて。
投稿をするのも投稿を読むのも、知らなかった誰かを知るのも「その時その場」のたまたまのできごと。
個人が使うツールとして、それまでの流行りだったコンテンツ蓄積系のブログに対する解答、てところだろう…ツイッターはまさにその最適解だと思ったんだけど。
ひらたく例えると「汲み取り便所に対する水洗便所」みたいなもの。
これは個人の好みとか志向なのでどっちがどうとは言えないし、用途次第ということもあるだろうけど、twitterやfacebookは水洗便所として登場したんだから、ちゃんと綺麗に流してほしい。
ツイートやフィードをアーカイブする、まとめることができたり、検索できたりするのは「リアルタイムWEB」の理念から遠いんじゃないかな。
そういったことは蓄積系のブログや従来のWEBページの役割だろうに。
前にどこかで書いたけど。奇想天外だかのかんべむさしと堀晃の昭和の頃の対談でのネタ。
駅のトイレに入ってたら「自分以外の時間が逆流を始めて」流そうとしていた自分のクソが便器の中で鎌首をもたげて、肛門を狙ってとびかかってくる恐怖。
ツイッターで検索できたり、アーカイブできたりするのはこういうこと（違
イーロン閣下ツイッターのグダグダで、ツイッターの後、ツイッター以外が話題になってる。
facebook、instagramと同じMetaがサービス開始したthreadsの恣意的に操作されるタイムラインなど論外で、ただただ流れる情報をたまたま何かの縁で拾える「袖すり合うも他生の縁」みたいな、リアルタイムWEBなSNSがあれば面白いんだけどねえ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
