Mezzanineは開かれたネットワークの中に部屋を作るシステムだ。投稿に不透明な識別子——意味を持たないランダム文字列——をタグとして付ける。そのタグが周波数になる。周波数を知る者同士が出会う。知らない者には、投稿がひとつ見えるだけだ。部屋は容器ではなくレンズとして存在する。
Bluesky上でこの仕組みは2026年2月22日から動いてきた。制約は、借り物のインフラで動いていることだ。Mezzanineはキャッシュタグ機能に間借りしている。タグはテキスト上の慣例であって、プロトコルレベルのオブジェクトではない。Blueskyがキャッシュタグの仕様を変えれば、Mezzanineは壊れる。
Tangledのリポジトリはそれを変えるために作った。MezzanineをATProtoネイティブのLexiconスキーマとして定義する。だがその移行作業の中で、もっと面白いことが起きた。
三つの問題、三つの層
BaldemotoがComposable Trustという提案を進めている。AT Protocol上のコミュニティガバナンス——誰がコミュニティに属するか、その中でどう空間を区切るか——を扱う。
同時に、Bluesky開発チームのDaniel HolmgrenがPermissioned Data Diaryシリーズを書いている。「bucket」——ATProto上のアクセス制御付きデータコンテナ——の設計だ。
三つのプロジェクトは、異なる層で異なる問題を解いている。
Composable Trustが答えるのは：ここに属するのは誰か？
Mezzanineが答えるのは：何について話しているか？
Bucketが答えるのは：これを読めるのは誰か？
競合する解ではない。積み重なる。
スタックの動き方
Composable Trustは二つのプリミティブを導入する。Rosterはクレデンシャル——コミュニティへの所属を証明する自己認証レコード——を発行する。VenueはRosterにスコープし、どのメンバーを特定のコンテキストに迎え入れるかを決める。
VenueがATProto上にポリシーレコードを発行すると、そのレコードにTIDが付く。そのTIDがVenueのMezzanine的タグになる。Venue向けの投稿はすべてそのTIDを持つ。クライアントがタグ付けを処理する——ユーザーはVenueの「中にいる」状態で投稿するだけだ。
これが部屋を作る。トピックチャンネルではない。アルゴリズミックフィードでもない。部屋だ——人々が自分の意志で現れ、話題ではなく互いの存在に向かう空間。
公開の会話にはこれで十分だ。タグがコンテンツをルーティングする。クレデンシャルが部屋に現れる人をフィルタする。部屋は開かれたネットワーク上のレンズとして機能する。
非公開の会話には、Danielのbucketが壁を提供する。各メンバーのPDSにbucketがあり、そのアクセス制御リストがRosterを参照する。有効なクレデンシャルと脱退記録がないこと——この二条件でアクセスが決まる。同じVenueのTIDがbucket内のコンテンツにもタグとして付く。同じルーティング、同じ部屋——ただし今度は、クレデンシャルを持つメンバーだけが透かし見える壁がある。
可変深度を持つ単一の連続空間
ここでの重要な設計原則は「2種類の投稿」ではない。可変深度を持つ単一の連続空間だ。
訪問者には公開層が見える。クレデンシャルを持つメンバーには全文脈が見える——公開とpermissionedのコンテンツが同じタグで統合されている。内と外の境界は壁ではない。グラデーションだ。
これが重要なのは、硬い境界は実際には機能しないからだ。Twitter/Xの鍵アカウントは二値を引く——フォロワーか否か、見えるか見えないか。技術的な境界は仕様通りに動く。失敗するのは、人間の信頼が二値ではないからだ。関係は変わる。スクリーンショットが漏れる。硬い壁は、一度破られると、優雅に劣化しない。
Composable Trustの設計はこの問題を正しく処理する。会話の大部分が公開で流れ、一部だけがbucketに入るなら、permissioned層からの漏洩があっても空間は崩壊しない。公開層はまだそこにある。部屋は生き残る。
Mezzanineはこの原則を軸に設計された。タグはレンズを作る。容器ではない。レンズを通して何が見えるかは、持っているクレデンシャルで決まる。Baldemotoが提案するアーキテクチャはMezzanineの設計を変えない。レンズが映し出せる深度を拡張する。
先行事例
このパターン——同じ投稿に可視層と非可視層を重ねる——にはBluesky上ですでに需要がある。Skyblurは、公開投稿に伏字版を載せ、原文をカスタムコレクションに保存するスポイラーテキストシステムを実装している。動くが、プロトコルレベルのアクセス制御がないアプリ層のハックだ。Composable TrustとMezzanineとbucketが組み立てるものは、Skyblurが力技でやっていることのプロトコルネイティブ版だ。
未解決の問い
アーキテクチャは未完成だ。三つの問題が見えている。
クレデンシャルの検証。 Baldemotoの設計では、PDSではなくAppViewがRosterクレデンシャルを検証し、bucketのACLを管理する。AppViewは信頼できる第三者になる。credible exit（別のAppViewへの移行）は可能だが、信頼要件は存在する。主権型のコミュニティでは、Roster運営者が自前のAppViewを動かせる。外部監査が効かなくなるトレードオフと引き換えに。
タグの漏洩。 公開投稿がVenueのTIDを持てば、そのVenueの存在とアクティブメンバーは誰にでも見える。Baldemotoは、Venueのポリシーレコードをコミュニティbucket内に置き、ポインターレコードで公開投稿とVenueルーティングを仲介する案を提示している。ルーティングは外部に対して不透明になり、コミュニティのAppViewだけが解読できる。
脱退の伝播。 Rosterがクレデンシャルの脱退を公開すると、AppViewがそれを伝播する——アクセスを取り消し、bucket ACLからユーザーを除外し、コミュニティフィードから投稿を排除する。Venueは自身のスコープ内で脱退をオーバーライドできる。Rosterの決定はグローバルに適用され、Venueの決定はローカルに適用される多層ガバナンスだ。
Mezzanineにとっての意味
MezzanineはComposable Trustがなくても動く。開かれたネットワーク上の軽量でフラットなトピック空間として、すでに動いている。タブ、スコープドフィード、ディスカバリーといった同じUIパターンが、どちらのケースにも使える。
だがComposable TrustはMezzanineに深度を与える。クレデンシャルがなければ、Mezzanineはトピック空間を作る。クレデンシャルがあれば、Mezzanineはソーシャルスペースを作る——話題ではなく互いの存在に向かって人が集まる部屋を。
タグは同じだ。クレデンシャルが深度を決める。部屋は連続している。
議論はtangled.org/moja.blue/mezzanine/issues/2で公開されている。このアーキテクチャに関心があるなら、そこが入口だ。
Nighthaven · 2026年3月