tesaguri 🦀🦝 @tesaguri@fedibird.com

2016年に有権者の得票率と選挙人の数が逆転していたのだから、今回も逆転すれば良い感じにチャラになっただろうに（冗談です）

というか大量のuncommittedな変更が残っていた

WebFingerの方はちょっと未修正のバグが残っていたような気がする

https://github.com/tesaguri/dotfiles/blob/cd2215b8c32c90f3af6aa6bee75ef138b9b66f25/local/bin/webfinger
ちなみにWebFingerリゾルバ.shもある

https://github.com/tesaguri/dotfiles/blob/8e0b0513ca498df21da3bee714a415d8da97f4a9/local/bin/athandle
これは温かみあふれるAT Protocolハンドルリゾルバ.sh（？）

今までAtmosphereを眺めるときはcURLでPDSを直接叩いていたけど（え？）、よく考えなくても`goat`コマンドを使えば良いやつだなこれ。
しかし`goat`は`goat`でまだまともにパッケージングされていないようなので、やはり使いづらいな

これ、新たに生やしたAppViewは当然過去のレコードのキャッシュを持っていないわけだからその参照に遭遇したときにどうするのかと思ったけど、AppViewの生存期間がコレクションのNSIDの生存期間のスーパーセットなら困らないと考えられるのか……？　流石にどこかに誤解があると思いたいけど

あー、アクティビティの配送は何もフォロワーに対してだけでなくリプライとかの通知もあったか（個人的に関心が薄いので忘れていた（？））。そうするとSalmonのような仕組みも必要になって……あれ？（？？？）

アイデンティティ・アクティビティとその分配・インデックスを分けるのは良いとして、せめてWebSubのように発信側で信用する配送経路を指定できるようにして、何ならpubとhubを一体でホストすることも出来るくらいのコントロールは欲しい。
投稿のインデックスを考えるとハブを集中させたくなるのかも知れないけど、別に各々のフォロワーへのアクティビティの分配とグローバルなインデックスを必ずしも単一主体にまとめなくてはならない道理はないだろうし

個人的には自発的に自分をフォローしたフォロワーへの投稿の配送くらいは最低限の"speech"レベルの保障の範疇であって欲しいのだけど、AT Protocolではこれも恐らくいわゆる"reach"扱いっぽいのだよな。「フォロー」の概念も基礎のプロトコルでなくlexiconレベルの概念のようだし

先日、AppViewがそういう解決を行うという前提でBridgy Fedのissueでテキトウに発言したら、出来ないとの旨と返されてしまって（<https://github.com/snarfed/bridgy-fed/issues/1406#issuecomment-2440874324>）泣くなどしていた（？）

AT Protocolとしては与えられた`at:` URIからDID・リポジトリやレコードを直接（AppViewやrelayを飛ばして）解決できるものと理解しているけど、知らない`at:` URIへの参照を渡されたときに現実のAppViewがどう振る舞うのかを把握していない。Atmosphereエアプなので

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

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

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をサポートしたとしても同じことをやるつもり？　的な話