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とかもそのような扱いを前提とした仕様に見える

ログインして会話に参加
Fedibird

様々な目的に使える、日本の汎用マストドンサーバーです。安定した利用環境と、多数の独自機能を提供しています。