ActivityPubからAT Protocolのブリッジについてはどうしてもdata repositoryへのデータの複製・再頒布を伴うからオプトインが妥当だと思うけど、逆方向についてはAPサーバというのは単なるプロクシとして振る舞えるので、一般のAppViewと同じくオプトインなしで閲覧できるようにしても問題ないのではという気がする。ATPのアクセス制御はAPのそれのサブセットくらいの強さしかなさそうだし
`!no-unauthenticated`ラベルとかいうのもあるけど、ActivityPubサーバをAT ProtocolのAppViewと見做すならそのユーザに見せる分には問題ないのでは。知らんけど
フォロー
オプトインにでもしないとブリッジが乱立するという問題はあるだろうけど、そこはFEP-fffd proxy objectsとかで良い感じに重複排除するような方針もありうるだろうし
そういえばAT ProtocolではActivityPubと違ってリプライの許可範囲の意思表示の仕組みが確立しているのだったか。
一応Activity Streamsでも`replies`コレクションを管理するのはリプライの受信者のサーバであるし、ActivityPubでも`inReplyTo`の副作用は特に定められていないはずだからプロトコル上は受信者がリプライを制御していると考えられなくもないけど、実際は`inReplyTo`が副作用として無条件に対象オブジェクトの`replies`コレクション相当のキャッシュにリプライを追加する扱いが一般的だし、ActivityPubのinbox forwardingとかもそのような扱いを前提とした仕様に見える