tesaguri 🦀🦝 @tesaguri@fedibird.com

https://enby.life/notes/9z9oy3oifj
偶然目に付いたノートの添付のスクリーンショットがめちゃくちゃ見覚えがあるやつでひっくり返っていた

あるいは「新しい」リポジトリの過去の投稿を（ユーザタイムライン以外に）fan outしないという手もあるか。その場合、DIDドキュメントの`created`より古い`createdAt`を持つレコードを無視するとすれば決定論的な振る舞いになるかな。
DIDを確保した後に作られた投稿を後からインポートするといったことを考え始めると面倒だけど、そんなことはそうそうあるものだろうか。うーん、人間が直接使っていたリポジトリを後からブリッジに転用するようなケースはありうるかな

言葉が足りないな。つまり、AT Protocol側ではfirehoseから投稿を取得していると仮定して、firehoseから「古い」投稿が配送されたときにそれをそのままActivityPubのフォロワーに転送するべきか、あるいは即座には転送せず`/convert/ap/at://*`からの明示的なfetchに対してのみ返すようにするべきか、そして後者だとすれば「古さ」の閾値をどこに設定するべきか自明でないという話

受信者側で"Alice liked a Tweet you were mentioned in"のような通知を表示するユースケースを想定して、`Like`アクティビティを`object`の`Mention`の`href`の`inbox`にも送りつける実装（色々な実装）

しかしこれ、ブリッジアカウントがどう振る舞うべきかはあまり自明でないか。Bridgy Fedはfirehoseから投稿を取得しているのだっけか？（何も調べずに書いている）
QT: https://fedibird.com/@tesaguri/113417002334770843 [参照]

要は、それWordPressがAT ProtocolのPDSをサポートしたとしても同じことをやるつもり？　的な話

まあActivityPubでも古いアクティビティをいきなり大量に配送したら迷惑行為と看做されるかもしれないけど、古いオブジェクトを後から取得するという操作は一般的だし、普通はそれでも破綻しないように実装で考慮されるよね（よね？）

ianklatzco/twitter-to-bsky: import a twitter archive into bsky
https://github.com/ianklatzco/twitter-to-bsky
> Bluesky's UI currently renders timestamps based on the indexedAt field (i.e., when the skoot was skooted) rather than the createdAt field (when the skoot CLAIMS it was skooted).
> The code here currently tries to post skoots with the old timestamps, but the Bluesky UI will not render them so. It used to, and then Paul probably patched the bug ^^
過去のデータ（から変換されたレコード）を持ったリポジトリを新たに連合させるというのは正当なユースケースだろうし、それでスパムになるのだとしたらそれはBlueskyの問題だよなあ

MacBook Airのノッチが邪魔で仕方ないので、ディスプレイの解像度設定で縦幅を減らしてノッチを領域外に追いやったものの、これだとノッチがある画面上部だけでなく下部の方にも微妙に未使用の領域が発生するのがもどかしい

`ddrescue`の名前を挙げてもらっていなかったらずっと`dd`でどうにかしようと足掻いていたと思うのでありがたい🙏

そういえば元のラップトップでも近頃はやけにハングするようになっていたな。
どうしてここまで放っておいたんですか？？？　はい……

しばらくすると切断されるというよりは、正確には不良セクタが14個ほどあって、それらを読もうとするとハングして切断されるといった様子だった。
それらを`-i`オプションで適宜読み飛ばさせながら`ddrescue`を繰り返したら取りあえずマウント可能なイメージを作れた。どこかしらで整合性がおかしいのだろうけど、まあ大体読めるので良し

RAMとSSDも前の2倍だし十分でしょ。なお前のRAMとSSDは4 GiB/128 GiB（？）

内臓SSDを認識しなくなったラップトップは流石に買い替えたけど、ちょうどM4 MacBook Proが発表されているようなタイミングで間が悪すぎる。まあ別に良いけど

まあ100日以上前のバックアップに復元するような羽目にならなくてよかった（こまめにバックアップしろ、はい……）

取りあえずSSDをパチモンのエンクロージャに移して必要なデータは一通り拾えた。
本当なら全て`dd`で吸い出したいところだけど、しばらくすると勝手に切断されてしまうような状態なので、これ以上は少なくとも自分では触らない方が良さそう

何ならプライバシーの要件も無視して良いだろうから、リモートのオブジェクトの取得もbot側に押し付けられるかな。キャッシュが欲しいなら各々クライアントサイドでやれば良いし。Signed fetchのためにいずれにせよ`proxyUrl`は必要だろうけど

人間のユーザーの場合は複数のクライアントから任意のタイミングでタイムラインや通知を取得しうるのに対して、botの場合は常駐していることを期待して良いだろうから、例えばfan outはストリーミングAPIに流し込むだけに留めてタイムラインのキャッシュは抑制するといった戦略が取れるだろうか。ある程度backfillingに対応する必要もあるだろうけど