Your Follower List, Their Record: ブロ解要求における自己主権と他者レコードの衝突

1. Overview Bluesky日本語圏で、いわゆる「ブロ解」——ブロックによって相手からの自分へのフォローを強制的に剥がし、その後ブロックだけを解除する儀式——が実装されていないことへの不満が繰り返し観測される。議論は当初、技術的な実装可能性の問題として扱われた。他人のフォローレコードを操作できない、AppView層で見かけ上のフォロー関係を捏造する処理になる、といった論点である。しかしこの技術的制約の裏には、より深い衝突が伏在している。自己のフォロワーリストを編集する権利と、他者がフォローレコードを保持する権利の非対称な衝突である。本稿はブロ解要求を、この二つの主権の衝突として再記述する。
2. Definitions 客観的ネットワーク構造：フォロー関係の集合として記述できる有向グラフ。各エッジは一つのフォローレコードに対応する。フォローレコードは常にフォローする側のユーザーに帰属する。 主観的ネットワーク認知（SNC）：個々のユーザーが「自分のネットワーク」として体験している像。フォロワーリスト、フォロー中リスト、タイムラインなどを含む。ユーザーごとに異なる。Network Perception理論が対象とする層である。 レコード主権：自分が作成したレコードを自分以外が削除・改変できないという原則。ATProtoの基本設計に組み込まれている。 SNC主権：自分のSNCを自分の意思で編集できるという原則。フォロワーリストの整理、タイムラインの構成などを含む。 ブロック（bsky.appにおける）：相互の可視性を遮断する操作。実行時、自分から相手へのフォローレコード（自分が作成したレコード）は削除されるが、相手から自分へのフォローレコード（相手が作成したレコード）は削除されない。フォロー関係の解消は非対称であり、自分の側のレコードのみに作用する。他者のレコードには介入しない。 ミュート：自分のタイムラインから相手を除去する操作。フォロー関係には影響しない。相手には通知されず、相手のSNCにも影響しない。 ブロ解：Twitter等の中央集権型SNSで成立した儀式。ブロックによって相手からの自分へのフォローを剥がし、その後ブロックを解除する。結果として相手のフォロワーリストから自分が消え、自分のフォロワーリストから相手が消える。Blueskyでは原理的に成立しない。ブロックが他者のフォローレコード（相手→自分）に介入しないため、ブロックしても相手は自分をフォローしたまま残る。日本語圏で観測される「ブロ解できない」不満は、この原理的不可能性に由来する。
3. Propositions P1：ブロ解要求の中核は、自分のフォロワーリストから特定の相手を消すことにある。Blueskyのフォロワーリストは相手が作成したフォローレコードの集合であり、自分はそれを編集できない。要求は自己のSNC編集への欲求だが、Blueskyの設計ではフォロワーリスト自体が他者レコードで構成されているため、この欲求は原理的に実現手段を持たない。 P2：ブロ解の実現手段は、相手が作成したフォローレコードの削除である。目的は自己のSNC編集だが、手段は他者レコードの操作になる。目的と手段のレイヤーが食い違う。 P3：ATProtoの「他人のレコードを操作できない」という設計原則は、レコード主権を保証する。この保証は同時に、SNC主権の一部を制限する。すなわち、他者のフォローレコードを消す権利を自分が持たない以上、自分のフォロワーリストを完全に編集する権利も持てない。 P4：レコード主権とSNC主権は、フォロー関係において非対称に衝突する。自分のフォローレコードの削除は、レコード主権の範囲内でありSNC主権の範囲内でもある。しかし相手のフォローレコードの削除は、相手のレコード主権を侵害しつつ自分のSNC主権を実現する。この非対称性はフォロー関係の有向性に由来する。 P5：Twitter時代のブロ解が成立していたのは、中央集権アーキテクチャが他者レコード介入を暗黙に許容していたからである。運営が全てのフォロー関係を単一のデータベースに保持し、ユーザーのブロック操作を通じて他者レコードの削除権限を委譲していた。Blueskyのブロックは自分のレコードのみに作用する。この違いがブロ解成立の可否を分ける。
4. Corollaries C1（P1, P2より）：ブロ解要求者は、自分のフォロワーリストを「自分のもの」と認識している。しかしBluesky上では、フォロワーリストは他者が作成したレコードの集合として表示されるだけの投影である。「自分のフォロワーリストを編集する」という行為自体が、所有権の所在についての誤認に基づいている可能性がある。 C2（P2, P3より）：ブロ解をAppView層で「見かけ上のフォロー解消」として実装する提案は、手段のレイヤーを変えることで目的を達成しようとする試みである。他者レコードは保持しつつ、そのレコードの効力をAppView側で無効化する。これはレコード主権を形式的に守りつつ実質的に侵害する設計であり、分散型プロトコルの整合性を損なう。 C3（P4より）：SNS上のすべての機能は、レコード主権とSNC主権の境界のどこに位置するかで再分類できる。ミュートは両主権と衝突しない。ブロックはレコード主権とは衝突しないがSNC主権の相互認識を制限する。ブロ解はレコード主権と衝突する。引用ポストやリプライは、相手のレコードを参照することでSNC主権を相互に侵食する。 C4（P5より）：中央集権型SNSでは、運営がすべてのユーザーのレコード主権を保有している。ユーザーは運営から委譲された範囲でレコードを編集できる。分散型プロトコルはこの委譲構造を解体し、各ユーザーに直接レコード主権を配分する。結果として、他者レコードへの介入を前提とした機能は原理的に実装できなくなる。 C5（P1より）：「迷惑をかけたらブロ解してほしい」という発話群は、自己のSNC編集を他者に委ねる構造を示す。相手のフォロワーリストから自分を消す権利は、相手のレコード主権の範囲内にある。自分では消せないため、相手に実行を依頼する。ブロ解要求の背後には、自己のSNC編集と他者のSNC編集依頼が対称に存在する。
5. Open Questions Q1：ブロ解が実装可能になった場合、レコード主権の侵害は一回の操作に限定されるか。一度他者レコードの削除を許容すれば、他のレコード型（いいね、リポスト、リプライ）への波及は技術的に防げるか。 Q2：自己のSNC主権の範囲はどこまでか。自分のフォロワーリストは自分のものか、それともフォローしてきた他者たちのレコードの集合か。前者ならブロ解は正当化される。後者なら現状の設計が正しい。この問いは所有の概念そのものに関わる。 Q3：中央集権アーキテクチャが暗黙に許容していた他者レコード介入は何だったか。ブロ解以外にも、アカウント凍結、投稿削除、フォロー関係の一括整理など、ユーザーが当然視していた操作の多くが他者レコードへの介入を含んでいた可能性がある。分散型プロトコルへの移行は、これらの介入を一括して再検討する機会になる。 Q4：レコード主権とSNC主権の衝突は、文化圏によって解決の優先順位が異なるか。日本語圏でブロ解要求が顕著である観察は、関係終了の儀式化がSNC主権を優先する文化的傾向を反映している可能性がある。他言語圏での同じ機能への需要と比較する必要がある。 Q5：分散型プロトコルが提示する「各ユーザーへの主権配分」は、実質的な権限の分配として機能しているか。レコード主権は形式的に分配されているが、AppView層を通じた閲覧体験の制御は依然として中央化されている。主権の分散は階層ごとに異なる度合いで実現されている可能性がある。

Discarded Hypotheses

• Blueskyのブロックはフォロー関係を双方向に解消する

棄却理由：Blueskyのブロックは自分が作成したフォローレコードのみを削除する。相手のフォローレコードには介入しない。この非対称性がブロ解の原理的不可能性を生む。

• ブロ解はBluesky上で実装されていないだけである

棄却理由：実装されていないのではなく、ブロックの現在の定義のままでは原理的に成立しない。ブロ解を可能にするには、ブロックの定義自体を変更して他者レコードの削除を含める必要がある。これはATProtoのレコード主権原則の変更を意味する。