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の問題だよなあ

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

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

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

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

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

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

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

ところで出典も示してくれていたら嬉しかったね（？）
https://codeberg.org/fediverse/fep/src/branch/main/fep/268d/fep-268d.md

あー、Fedibirdだとw3id.orgのリダイレクトが解決されてしまうのだった