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のような仕組みも必要になって……あれ？（？？？）