むかしMisskeyフォークでインポート機能がバグってた時にもあったけど、
Bridgy FedしてるBlueskyアカウントで、Twitter投稿をインポートするスクリプトかなんかを使ったのかな？ 大量に新規投稿としてこっちに流れてきているのを観測している。
なので、2012年の投稿とか流れてきてる。まだActivityPubのない時代だねえ。
これかな。
twitter-to-bsky importer
https://github.com/ianklatzco/twitter-to-bsky
⚠️⚠️ 注意書き ⚠️⚠️
At this time, this will spam others timelines, so it is only recommended to run on new accounts with no followers. See Known problems below for details.
（意訳：フォロワーのいるアカウントで使うと全投稿垂れ流してスパム挙動になるからやったらアカンで）
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のリダイレクトが解決されてしまうのだった
AT Protocolとしては与えられた`at:` URIからDID・リポジトリやレコードを直接（AppViewやrelayを飛ばして）解決できるものと理解しているけど、知らない`at:` URIへの参照を渡されたときに現実のAppViewがどう振る舞うのかを把握していない。Atmosphereエアプなので
先日、AppViewがそういう解決を行うという前提でBridgy Fedのissueでテキトウに発言したら、出来ないとの旨と返されてしまって（<https://github.com/snarfed/bridgy-fed/issues/1406#issuecomment-2440874324>）泣くなどしていた（？）
個人的には自発的に自分をフォローしたフォロワーへの投稿の配送くらいは最低限の"speech"レベルの保障の範疇であって欲しいのだけど、AT Protocolではこれも恐らくいわゆる"reach"扱いっぽいのだよな。「フォロー」の概念も基礎のプロトコルでなくlexiconレベルの概念のようだし
アイデンティティ・アクティビティとその分配・インデックスを分けるのは良いとして、せめてWebSubのように発信側で信用する配送経路を指定できるようにして、何ならpubとhubを一体でホストすることも出来るくらいのコントロールは欲しい。
投稿のインデックスを考えるとハブを集中させたくなるのかも知れないけど、別に各々のフォロワーへのアクティビティの分配とグローバルなインデックスを必ずしも単一主体にまとめなくてはならない道理はないだろうし
あー、アクティビティの配送は何もフォロワーに対してだけでなくリプライとかの通知もあったか（個人的に関心が薄いので忘れていた（？））。そうするとSalmonのような仕組みも必要になって……あれ？（？？？）
これ、新たに生やしたAppViewは当然過去のレコードのキャッシュを持っていないわけだからその参照に遭遇したときにどうするのかと思ったけど、AppViewの生存期間がコレクションのNSIDの生存期間のスーパーセットなら困らないと考えられるのか……？ 流石にどこかに誤解があると思いたいけど
今までAtmosphereを眺めるときはcURLでPDSを直接叩いていたけど（え？）、よく考えなくても`goat`コマンドを使えば良いやつだなこれ。
しかし`goat`は`goat`でまだまともにパッケージングされていないようなので、やはり使いづらいな
https://github.com/tesaguri/dotfiles/blob/8e0b0513ca498df21da3bee714a415d8da97f4a9/local/bin/athandle
これは温かみあふれるAT Protocolハンドルリゾルバ.sh（？）
https://github.com/tesaguri/dotfiles/blob/cd2215b8c32c90f3af6aa6bee75ef138b9b66f25/local/bin/webfinger
ちなみにWebFingerリゾルバ.shもある
WebFingerの方はちょっと未修正のバグが残っていたような気がする
2016年に有権者の得票率と選挙人の数が逆転していたのだから、今回も逆転すれば良い感じにチャラになっただろうに（冗談です）
tesaguri@fedibird.com profile - Bridgy Fed
https://fed.brid.gy/ap/@tesaguri@fedibird.com
`Tombstone`が残っているわけでもない`Delete`の記録が表示されるのがちょっとアレだな
【期間限定】Grayish Heaven／シマハイイロギツネ【 #けもV #シマハイイロギツネ #シマハイシン 】 - YouTube
https://www.youtube.com/watch?v=gV5g-XTyIW4&list=PLWJQ4ynLJHy3pmvbLQ10f59LceN0nHFny&index=6
複数ページなあ。まあ<https://html.spec.whatwg.org/>や<https://262.ecma-international.org/>くらいのサイズまでなら単一の文書に突っ込んでも意外と問題ないのでは（いいえ）
素朴に考えるなら、オブジェクトを分割して`next`と`prev`リンクで繋ぐとかかな
https://www.iana.org/assignments/link-relations/link-relations.xhtml
あとは`first`/`start`/`last`や`index`も欲しいか？
しかし、`first`/`last`の定義は不詳で`start`/`index`はHTML 4.01による定義（Living Standardには無い）というのは、何とも微妙だな……
FirefoxのResist Fingerprintingはビューポートのデフォルトのサイズを200x100の整数倍に切り捨てる仕様のはずだけど、何故か起動時に最初に開かれるウィンドウとRecently Closed Windowsから開いたウィンドウとプライベートブラウジングの場合に限って本来より1px低いものになる症状に悩まされている
実際Cover Your Tracksでもかなり情報量の多いフィンガープリントとして報告される（後者の画像は参考のために100pxの倍数の高さに調整した場合の結果）
まっさらなプロファイルでも再現するから、環境に依らない不具合と見て良さそうかな。報告するにしても既存チケットがないか調べるのが面倒臭いな……
今まで何も考えずにSnowflakeプロクシ（<https://snowflake.torproject.org/>）を走らせていたけど、そういえばプロクシを走らせる環境でVPNを設定していても良いものなのだろうか
余剰の計算リソースをFolding@homeに費やしているような人はついでに帯域リソースをSnowflakeに費やしておくと良いですよ（？）
Misskeyも通報の連合してる…よね…？
してると思ってガンガン飛ばしてたけど、連合してないなんてこと…まさか… 
こういうのを調べるときはソースコードを該当するアクティビティで検索して当たりを付けるのが定石だと思っているけど、確か報告の連合はActivityPubでは規定されていないのだよな。現行のFediverseの慣習では`Flag`アクティビティだったっけ？
このアカウントは、notestockで公開設定になっていません。
Mastodonでは対象のサーバに転送するか否かはユーザによる選択式だったと思うけど、Misskeyでは管理者が選ぶのかな？
プロトコルレベルでは報告を行うユーザ自身でなく代理のアクターが`Flag`アクティビティを送る慣習らしいというところまでは認識しているけど、宛先のアクターは具体的にどう決定されるのだったっけ。`Block`とかについてもそうだけど
https://github.com/misskey-dev/misskey/blob/5229f5de4d9ef7cd75d32466d29d672193adaf45/packages/backend/src/core/AbuseReportService.ts#L144
Misskeyでは対象ユーザのアクターか。
まあいわゆるシステムアクターを安定して特定する仕組みとかも特に確立していないし、それはそうか
機械に疎いので、ゆうちょ通帳アプリで二次元バーコードを読み取る手順を毎度調べ直している
うおおおおお、私は外出先でテザリングしながら`docker pull`するぞおおおおお
投稿の編集を肯定しようがしまいが、content-addressedとかなわけでもないデータを連合している以上はリモートのオブジェクトが勝手に書き換わることを妨げられないわけで、オブジェクトの編集の受信をサポートしなければオブジェクトを受信したタイミングによって異なる表現を掴まされうるという問題を抱えるだけだよね
（まあ理論上の問題としては受信のタイミングだけではなくて、例えば接続元やkeyid等によって異なる表現を出し分けられるとか、何ならfetchの度にランダムに異なる表現を返されるとか、あらゆる可能性を想定できてしまうのだけど）
申し訳ないとは思っている。いやほんと、申し訳ないとは思っているのよ
