ちょろちょろ改修してるんで、忘れないようにメモ。

5分以上前の自分はあかの他人、だからなぁ。

おひとり様ActivityPubサーバーのソースコードを外部モジュール化した。

ため池とcron側と両方共通して使うルーチンばかりで、ふたつのファイルに対して同じ修正するのが面倒くさくなった（今さらかよ）ここんとこ1ファイルでやっつける安いスクリプトしか書いてなかったんで、久しぶり。

これで改修やつけ足しも楽になった。

Like一覧・Mention一覧をつけ足した。

LikeはWeb拍手がわりの使い方のほか、ブックマーク的な使い方もしてるので一覧ページが欲しかった。イベントや博物館美術館情報の展示情報など、わたし的に貴重な情報が多い。

LikeのJSON保存は個数制限は外して期間制限だけにした。上限14日間。

Likeを削除するのはウチだけの話。意図してLikeを外すワケじゃないのでUndoは飛ばさない。

Likeの情報はお相手の所属するサーバーが持ってるんでこちらでLikeのJSONを削除しても影響はない。こんなところも分散型、ActivityPubの特徴、ということだなあ。

わたし宛のMentionはデータベースに登録してもいいと思ったんだけど、なにかの拍子に（Fediverseに）飛ばしてしまうと危険なので、とりあえずJSONそのまま保存。一覧して確認できればいいかな、ぐらいの感じ。

サークル機能に対応（？）

飛んでくる投稿はCreateというActivityの中のobjectという箱に入ったNoteがその実体。なので、投稿を取り出すにはCreateというActivityのJSONをデコードしてobjectを取り出す。

objectには投稿本文や投稿日時など投稿についてのすべての情報がハッシュ配列になって格納されている。

…てのが、ほとんどなんだけど。

objectがハッシュ配列じゃないActivityが飛んできてエラーとなってロックがかかってビックリ。配列じゃないobjectなんてまったくの想定外だった。

JSONを覗いてみたらobjectが配列じゃなくて、1行の文字列。

HTMLエンコードされたURIとなにやらハッシュ文字列とキーワードっぽいbearという文字。投稿の宛先や投稿者、投稿日時がないんだけど大丈夫か。

エンコードされているURIにブラウザでアクセスしてみたら400番代のエラーページが表示される。ハッシュ文字列がOAuthっぽくもあるけどなんのこっちゃわからない。

手がかりがまったくなくて困って、ため池に投稿したらFedibird管理人ののえるさん（@noellabo@fedibird.com）に拾ってもらって、該当ドキュメントを教えてもらった。

https://docs.joinmastodon.org/spec/bearcaps/

詳細はこちらにも↓

https://fedibird.com/@noellabo/104790008237308249

飛んできたobjectのURIに対して、GETリクエストする時のヘッダにAuthorizationをつければ問題なくURIを開くことができて、内容を読めた。宛先がない投稿を勝手に開いていいのかという問題は残るので、要調査。

とはいえ、これは投稿として開いて読む場合。サークル機能？にこちらからリクエストを投げる時は投稿先などちゃんと調べなきゃダメ。今日はとりあえず読むところまで。

まだまだわからないことだらけだ。

初詣の神社はアスクル御神籤でありがたみもないんで、昨日改めて浅草寺。

ここは「凶」が多くてひとに厳しい御神籤なんだけど、今年は一発で「吉」を引けた。去年がいろいろ厄年だったので、これで今年がいい年になればいいなぁ。

[更新]2024-01-18 08:49:54

EPUB3でDRMはどうするの？という昨日の記事（「EPUB電子書籍のDRM」 http://t2aki.doncha.net/?id=1358226885 ）の続き。

…たぶん、役に立たないので、ネタ程度の扱いでよろしく。

ソーシャルDRMというのか、電子書籍に買ってくれたひとのメールアドレスなりを埋め込んでおく、というやりかたがある。それをEPUB3にも入れてみよう、ということでごそごそお試し中。

EPUB3はzipで解凍するとただのテキストファイル、HTMLファイルなのでメールアドレスを埋め込んだところで簡単に削除できる。ここを少し面倒くさくしておく必要がある。「いちいち開いて編集して、また梱包しなおしてやるより買った方が早い」というのがポイント。

ウチのページ、「EPUB3::かんたん電子書籍作成」では、見出しごとのファイルに分割する（EPUB3リーダーによっては一度に読み込めるファイルサイズに制限がある、という記事をどこかで見たので）

・数が多くて面倒くさくする。

短編小説はともかく、そこそこボリュームがあったり、ショートショート集だと、ファイルもそれなりに分割されて数が多くなる。そのファイルひとつひとつにメールアドレスを埋め込む。

・ぱっと見わかりにくくする。

メールアドレスは文字数値参照に変換しておく。

EPUB3は縦横混在可能。kindleのKF8でも縦書きの中に横書きの文字を入れることができる。サンプルはKDPの「ヘルプ」→「パブリッシングガイド」→「日本語サポート補足資料」にある

あとはこれ以外に、昨日の記事に書いたように content プロパティにもメールアドレスを埋め込み、さらに書誌情報 content.opf にも埋め込む。少しでも「面倒くさく思える」ように。

もちろん、こんな程度のもので、B2Bには使えない。

けど。試し読み版のような扱いのものなら、この程度の仕掛けで頒布してもいいかもしれない。かなあ。

（公開中のページに仕込むにはちょっと影響範囲が大きいので、別立てで作ってみるか）

[01/16 15:14:24] 追記。

メールアドレスだけじゃなくて、本文のテキストをすべて文字数値参照にしてしまう、というのもある種、暗号化だな（ほんまか）

[01/16 16:52:54] 追記。

本文テキストをすべて文字数値参照に変換して、改行や、インデントの余計な空白を全部削除（ストリップ）したら、中身は一見判別不能。かなり面倒くさくなった（もちろん、知識のある人間が見れば一発だし変換すれば戻せる、けど）

[更新]2013-01-23 10:17:32

というほど、ごたいそうなものじゃないんだけど。

twitterでよく見かける妙なURL。どうやら長いURLを短かくして使えるようにしている。文字数の制限が140文字なので、長いURLを貼り付けるのはもったいない。てことで、URLの短縮サービスなんだろうな。いくつか同じようなサービスがあるんだけど、どれがいいのかわからず、なんとなくメジャーっぽいので tinyURL というのを使ってみた。

http://tinyurl.com/api-create.php?url=

パラメータにurlエンコードしたURLを渡してやれば、素気ないテキストだけで短縮されたURLが返ってくる。今どき定番のxmlですらない。仕事がらみで、とりあえず便利に使わせていただくことにしてスクリプトに組みこんでみた。

でも、本当のURLを隠蔽することにもなるのはどうなんだろう。隠蔽が目的、というはまた別の話。せっかく希望するURLを取得したのに、それをわざわざ隠すのはちょっと抵抗がある。ウチのような長いURLだけど、欲くて取った名前だし、どうせ露出するならこの名前で出したい、のでウチには導入を見送り。仕事がらみの方だって、本当なら本当のURLを出した方がいいんだけどねぇ。

今日は朝から東京歯科大学水道橋病院。もう歯はガタガタだ。座して入れ歯を待つのみ。とほほ。

で、読書SNSって、ケータイからも本棚を検索できるようになっている。このスクリプトは、本体とは別の設計になってるので、そのまま使えばいいや。…なんて安直に思ってたわたしがバカだった。ログインのチェックのところで、こいつも本体としっかり同じことやってるんだった。

今回のリニューアルでは、ディレクトリ構成をちょっといじってログインの設定を変更して、アクセスの集中対策を施してみた。ケータイ用のスクリプトも当然そこを合わせないといけなかったのだ。そのまま使うということは今のサイトの状態も維持しておく必要がある。それはどう考えても無駄だし、危険。

とりあえず。ケータイはSJISなのでちょっと混乱したけど、リニューアルサイトに合わせて移植できた、かも。

use utf8で、utfフラグさえついてれば、文字コードが違うもの同士で比較ができる、ってことに気づいてなかった。

if(文字：SJIS == 文字：utf8){てのがイケる}

って、何のためのutfフラグなんだよ、今さら。

後は、せっせとバグ取りして、スタイルシートのIE対応して、今月末にはリニューアル公開だ、な。

ウチの王、昨日あたりは食欲もあって少し元気になって目に力が戻ってきたように見える…んだけど、ヨメの話だと腎不全は治らないし予断を許さない状態に変わりないと。ううう。

サーバーからデータを取ってきてブロック要素にhtmlを流し込んで表示させる。てなことやってるんだけど、JavaScriptがよくわからんので、個々のやってることは単純。JavaScriptで、あのデータが欲しいと、サーバーのperlに伝えれば、perlがpostgresqlからデータを取ってhtmlにまで加工して返すので、それを特定のブロック要素にinnerTextで流し込むだけ。

ただ、perl、JavaScript、スタイルシートが絡むので、perlの出すhtmlが変なのかJavaScriptから渡したパラメータがおかしいのかスタイルシートがおかしいのか

、意図したものが出てこない場合の原因特定が面倒だ。

さらにおまけに、サーバー側ではmod_perl2のキャッシュ、ブラウザ側はJavaScriptのキャッシュで、apacheの再起動やらブラウザの再読み込みやらの必要もある。

alert、printを埋め込みまくり、tail httpd-error.logしまくり…。このあたりの効率を考えないと遅々として進まない。

[更新]2026-02-04 09:58:59