ATProto-native Lexicon definitions for Mezzanine, an information networking system using opaque cashtag connectors on Bluesky.
Initial commit: Mezzanine lexicon skeleton and spec v2.1.1
authored by
Moonblue
and committed by
Nighthaven
278b1a69
+476
+1
.gitignore
+1
.gitignore
···
1
+
.DS_Store
+53
README.md
+53
README.md
···
1
+
# Mezzanine Lexicons
2
+
3
+
ATProto-native Lexicon definitions for [Mezzanine (中2階)](https://plurality.leaflet.pub), an information networking system using opaque cashtag connectors on Bluesky.
4
+
5
+
## Overview
6
+
7
+
Mezzanine repurposes Bluesky's cashtag feature (`$` + alphanumeric string) as opaque connectors — they point without signifying. This repository defines ATProto Lexicon schemas to move Mezzanine from a text-convention layer to a protocol-native system.
8
+
9
+
## Namespace
10
+
11
+
`blue.moja.mezzanine.*`
12
+
13
+
## Architecture
14
+
15
+
### Phase 1: Annotation Layer (current)
16
+
17
+
Mezzanine operates as a metadata layer over standard `app.bsky.feed.post` records. Users post normally on Bluesky; a separate `blue.moja.mezzanine.tag` record annotates each post with its channel and role.
18
+
19
+
This is analogous to how `app.bsky.feed.like` annotates posts without modifying them.
20
+
21
+
| Lexicon | Type | Purpose |
22
+
|---------|------|---------|
23
+
| `blue.moja.mezzanine.defs` | defs | Shared types: channel tag format, post role enum |
24
+
| `blue.moja.mezzanine.channel` | record | Channel definition (tag + metadata) |
25
+
| `blue.moja.mezzanine.tag` | record | Post-to-channel annotation (subject + tag + role) |
26
+
27
+
### Phase 2: Native Post Type (future)
28
+
29
+
A dedicated `blue.moja.mezzanine.post` record type with its own AppView and feed generator. This would allow Mezzanine posts to exist independently of Bluesky's post schema.
30
+
31
+
## Mezzanine Spec
32
+
33
+
The full Mezzanine specification is maintained at:
34
+
- [mezzanine-spec-v2.1.1.md](./mezzanine-spec-v2.1.1.md) (snapshot in this repo)
35
+
- [Nightflight blog](https://plurality.leaflet.pub) (canonical)
36
+
37
+
## Channel Tags
38
+
39
+
Tags are 3–5 alphanumeric characters. First character must be alphabetic. Must contain at least one digit (to avoid collision with stock ticker symbols). Case-insensitive.
40
+
41
+
Current official channels:
42
+
43
+
| Tag | Purpose |
44
+
|-----|---------|
45
+
| `cT7aZ` | Anchor (meta/system) |
46
+
| `ATOPR` | AT Protocol ecosystem |
47
+
| `sT3m0` | STEM |
48
+
| `L1f3x` | Life |
49
+
| `cLt7r` | Culture |
50
+
51
+
## License
52
+
53
+
CC0 — Mezzanine concepts and schemas are free to use, modify, and redistribute.
+45
lexicons/blue/moja/mezzanine/channel.json
+45
lexicons/blue/moja/mezzanine/channel.json
···
1
+
{
2
+
"lexicon": 1,
3
+
"id": "blue.moja.mezzanine.channel",
4
+
"description": "A Mezzanine channel definition. Channels are named by opaque cashtag anchors and serve as frequency-based connectors, not semantic categories.",
5
+
"defs": {
6
+
"main": {
7
+
"type": "record",
8
+
"description": "Record representing a Mezzanine channel owned by the creating account.",
9
+
"key": "tid",
10
+
"record": {
11
+
"type": "object",
12
+
"required": ["tag", "createdAt"],
13
+
"properties": {
14
+
"tag": {
15
+
"type": "ref",
16
+
"ref": "blue.moja.mezzanine.defs#channelTag",
17
+
"description": "The cashtag anchor for this channel (without the '$' prefix)."
18
+
},
19
+
"label": {
20
+
"type": "string",
21
+
"maxLength": 64,
22
+
"description": "Optional human-readable label for the channel. Semi-transparent tags may use this for discoverability."
23
+
},
24
+
"description": {
25
+
"type": "string",
26
+
"maxLength": 300,
27
+
"description": "Optional description of the channel's theme or purpose."
28
+
},
29
+
"visibility": {
30
+
"type": "string",
31
+
"description": "Channel visibility. 'public' channels are discoverable; 'unlisted' channels require knowing the tag.",
32
+
"knownValues": [
33
+
"public",
34
+
"unlisted"
35
+
]
36
+
},
37
+
"createdAt": {
38
+
"type": "string",
39
+
"format": "datetime"
40
+
}
41
+
}
42
+
}
43
+
}
44
+
}
45
+
}
+21
lexicons/blue/moja/mezzanine/defs.json
+21
lexicons/blue/moja/mezzanine/defs.json
···
1
+
{
2
+
"lexicon": 1,
3
+
"id": "blue.moja.mezzanine.defs",
4
+
"description": "Shared definitions for the Mezzanine information networking system.",
5
+
"defs": {
6
+
"channelTag": {
7
+
"type": "string",
8
+
"description": "A Mezzanine channel tag: 3-5 alphanumeric characters, first character must be alphabetic, must contain at least one digit to avoid collision with stock ticker symbols. Case-insensitive.",
9
+
"minLength": 3,
10
+
"maxLength": 5
11
+
},
12
+
"postRole": {
13
+
"type": "string",
14
+
"description": "The role of a post within its channel. 'top' indicates an entry point; 'support' indicates supplementary content.",
15
+
"knownValues": [
16
+
"top",
17
+
"support"
18
+
]
19
+
}
20
+
}
21
+
}
+37
lexicons/blue/moja/mezzanine/tag.json
+37
lexicons/blue/moja/mezzanine/tag.json
···
1
+
{
2
+
"lexicon": 1,
3
+
"id": "blue.moja.mezzanine.tag",
4
+
"description": "An annotation record that links an existing app.bsky.feed.post to a Mezzanine channel. This is the Phase 1 approach: Mezzanine as a metadata layer over standard Bluesky posts, analogous to how likes and reposts annotate posts without modifying them.",
5
+
"defs": {
6
+
"main": {
7
+
"type": "record",
8
+
"description": "Associates a Bluesky post with a Mezzanine channel tag and role.",
9
+
"key": "tid",
10
+
"record": {
11
+
"type": "object",
12
+
"required": ["subject", "tag", "role", "createdAt"],
13
+
"properties": {
14
+
"subject": {
15
+
"type": "ref",
16
+
"ref": "com.atproto.repo.strongRef",
17
+
"description": "Reference to the app.bsky.feed.post being annotated."
18
+
},
19
+
"tag": {
20
+
"type": "ref",
21
+
"ref": "blue.moja.mezzanine.defs#channelTag",
22
+
"description": "The cashtag anchor (without '$' prefix) linking this post to a channel."
23
+
},
24
+
"role": {
25
+
"type": "ref",
26
+
"ref": "blue.moja.mezzanine.defs#postRole",
27
+
"description": "Whether this post is a 'top' (entry point) or 'support' (supplementary) post in the channel."
28
+
},
29
+
"createdAt": {
30
+
"type": "string",
31
+
"format": "datetime"
32
+
}
33
+
}
34
+
}
35
+
}
36
+
}
37
+
}
+319
mezzanine-spec-v2.1.1.md
+319
mezzanine-spec-v2.1.1.md
···
1
+
# 中2階（Mezzanine）情報ネットワーキング技法 仕様書
2
+
3
+
**Version:** 2.1
4
+
**Date:** 2026-03-04
5
+
**Author:** Nighthaven
6
+
7
+
**v2.1 変更点：** ルーマン・メソッド（核化原則）の導入。投稿密度の設計原則を追加し、公開投稿における知的財産保護と情報密度の最適化を明文化した。
8
+
9
+
---
10
+
11
+
## 概要
12
+
13
+
中2階（Mezzanine）は、Blueskyのキャッシュタグ（cashtag: `$` + 英数字）を**無意味なランダム文字列のアンカー**として転用する情報ネットワーキングシステムである。従来のスレッド構造を解体し、投稿の自律性と有機的接続を両立させる。
14
+
15
+
ハッシュタグが意味による分類を行うのに対し、中2階のタグは**不透明な接続子（opaque connector）**として機能する。指し示すが、意味しない。
16
+
17
+
理論的には、ルーマンのツェッテルカステンの社会化版であり、ウイルス型ではなく周波数型の情報流通モデルで動作する。
18
+
19
+
---
20
+
21
+
## 技術仕様
22
+
23
+
### キャッシュタグの制約
24
+
25
+
| 項目 | 仕様 |
26
+
|------|------|
27
+
| プレフィックス | `$`（ドル記号） |
28
+
| 文字種 | 英大文字・英小文字・数字（A-Z, a-z, 0-9） |
29
+
| 長さ | 5文字を推奨（3〜5文字が有効範囲） |
30
+
| 先頭文字 | 英字のみ（数字始まり不可） |
31
+
| 大小文字 | 区別なし（case-insensitive） |
32
+
| 組み合わせ数 | 5文字で約4,500万通り |
33
+
34
+
### タグ生成ルール
35
+
36
+
1. **無意味であること**が必須条件。意味を持つ英単語や略語を避ける
37
+
2. ランダム生成を推奨（付属のCashtag Anchor Generatorを使用可）
38
+
3. 既存のBluesky金融キャッシュタグ（`$AAPL`, `$TSLA` 等）との衝突を避ける
39
+
4. 汚染（他者が無関係な文脈で同じタグを使用）が発生したら、コストゼロでタグを放棄し新規生成する
40
+
41
+
---
42
+
43
+
## 投稿フォーマット
44
+
45
+
### トップポスト（主投稿）
46
+
47
+
本文の末尾にスペース1つ + タグを置く。
48
+
49
+
```
50
+
本文本文本文本文。 $xS0yV
51
+
```
52
+
53
+
### サポートポスト（補助投稿）
54
+
55
+
タグを先頭に置く。
56
+
57
+
```
58
+
$xS0yV
59
+
補足情報や関連する内容をここに書く。
60
+
```
61
+
62
+
### 出典リンク付きフォーマット
63
+
64
+
出典URLを1つ掲載する場合、以下のフォーマットを使用する。
65
+
66
+
#### トップポスト + 出典リンク
67
+
68
+
本文の後に1行空け、最終行にURL + スペース + タグを置く。
69
+
70
+
```
71
+
本文本文本文本文。
72
+
73
+
bsky.app/profile/example/post/xxxx $xS0yV
74
+
```
75
+
76
+
タグがURLの末尾に視覚的に紛れる効果がある。URL末尾の英数字列とキャッシュタグの見た目が近いため、タグの存在感が消える——**視覚的カモフラージュ**として機能する。中2階を知る者はタグをスキャンするため視認性に問題はなく、タグを目的外利用だと認識する層には認知コストが上がる。「知っている人だけがアクセスする」設計思想と一致する。
77
+
78
+
#### サポートポスト + 出典リンク
79
+
80
+
先頭にタグ、本文の後に1行空けてURLを置く。
81
+
82
+
```
83
+
$xS0yV
84
+
補足情報や関連する内容をここに書く。
85
+
86
+
bsky.app/profile/example/post/xxxx
87
+
```
88
+
89
+
### フォーマット判定基準
90
+
91
+
- トップポスト：そのチャンネルの「入口」となる独立した投稿
92
+
- サポートポスト：既存の文脈に接続する投稿、補足、反応
93
+
94
+
---
95
+
96
+
## ルーマン・メソッド（核化原則）— v2.1で追加
97
+
98
+
### ルーマンのカードに立ち返る
99
+
100
+
中2階はルーマンのツェッテルカステンの社会化版を標榜する。ルーマンのカードの実物を確認すると、1枚のカードは文字の壁ではない。典型的には1〜3文の短い記述、断片的で、余白が多く、カードの相当な面積を参照番号とリンク記号が占める。
101
+
102
+
**密度はカード単体ではなく、カード間のネットワークで生まれる。**
103
+
104
+
中2階の投稿も同じである。1投稿の密度を上げるのではなく、タグによるネットワークが密度を担う。
105
+
106
+
### 核化原則（Kernification）
107
+
108
+
中2階の投稿はBluesky上に公開される。パラグラフ単位で論証を展開すると、分析の筋道ごと他者に渡すことになる。公開しつつ知的財産を守るために、以下の原則を適用する。
109
+
110
+
1. **核だけを投稿する**：概念の命名、現象の切り取り、問いの提示。論証の展開・接続構造は投稿しない
111
+
2. **150字基準**：300字の上限を使い切る必要はない。150字前後で核が伝わるなら十分。残りの密度はタグによるネットワークが担う
112
+
3. **旗を立てる、地図は渡さない**：公開投稿は「この着想が存在する」という旗。旗と旗の間をつなぐ論理は、著者の頭の中と論文の中にだけあればいい
113
+
4. **削ることで守る**：リサーチクエスチョンになりうる問い、分析フレームワークの射程を見せる記述は、公開投稿から削る対象の第一候補
114
+
5. **サポートポストの独立性**：サポートポストは前の投稿の論理的な「次のステップ」にしない。各投稿は独立した核として読めるべきであり、連番で読んだときに分析の筋道が復元できてはならない
115
+
116
+
### 300字フル活用が適切な場合
117
+
118
+
すべての投稿を短くする必要はない。以下は300字を使ってよい。
119
+
120
+
- **ファクトの羅列**（数字・出典の列挙）：盗用リスクが低い
121
+
- **仕様の告知**（$cT7aZ）：正確さが最優先
122
+
- **掌編・創作**（$rMazF等）：作品としての完結性が必要
123
+
- **布教・説明目的の投稿**：わかりやすさが最優先
124
+
125
+
### 核化の判定基準
126
+
127
+
投稿を書いたら以下を自問する。
128
+
129
+
- その投稿から論証の筋道が復元可能か？ → 展開部分を削る
130
+
- サポートポストが前の投稿の論理的な次のステップになっていないか？ → 接続関係を断つ
131
+
- 分析フレームワークの適用範囲や射程が見えていないか？ → その部分を削る
132
+
133
+
---
134
+
135
+
## チャンネル運用原則
136
+
137
+
### 基本思想
138
+
139
+
- **フロー > ストック**：分類装置ではない。流れの中に置く
140
+
- **タグは選択であり義務ではない**：つけたいときにつける
141
+
- **チャンネルのテーマは入口であり、内容のドリフトを許容する**
142
+
- **放棄コストゼロ**：汚染されたら新しいタグを作ればいい
143
+
144
+
### 投稿時の設定
145
+
146
+
- **引用ポスト無効化**を推奨（中2階投稿に対して）
147
+
- **メンション無効化**を推奨（中2階投稿に対して）
148
+
- これによりシステムの完全性を維持する
149
+
150
+
### チャンネル構成
151
+
152
+
#### 三分類の設計思想
153
+
154
+
人類の投稿は3つに分かれる。知ること（STEM）、生きること（Life）、味わうこと（Culture）。これ以上細かく分けると分類装置になる。これ以上粗くすると意味がない。3が臨界点である。
155
+
156
+
公式チャンネルはこの三分類に、基幹タグと技術コミュニティ向けタグを加えた5チャンネルで構成する。
157
+
158
+
#### 半透明タグ（semi-transparent tag）
159
+
160
+
公式チャンネルのタグは完全ランダムではなく、テーマが薄く透ける程度の文字列を採用する。完全opaque（不透明）と完全transparent（透明）の中間——半透明タグと呼ぶ。
161
+
162
+
公式チャンネルは布教ツールでもあるため、初見の認知コストを下げる設計判断である。完全opaqueの美学は個人チャンネルで貫けばよい。この二層構造により設計思想は損なわれない。
163
+
164
+
#### 公式チャンネル一覧
165
+
166
+
| タグ | 用途 | 備考 |
167
+
|------|------|------|
168
+
| `$cT7aZ` | Anchor（中2階基幹・メタ情報） | 最初に作られたチャンネル |
169
+
| `$ATOPR` | AT Protocol（技術コミュニティ向け） | |
170
+
| `$sT3m0` | STEM（AI・言語学・Network Perception・技術） | 半透明タグ |
171
+
| `$L1f3x` | Life（日常・小話・文具） | 半透明タグ |
172
+
| `$cLt7r` | Culture（読書・視聴・エンタメ・掌編） | 半透明タグ |
173
+
174
+
これらは公式チャンネルであり、誰でも自由に個人チャンネルを作成できる。
175
+
176
+
---
177
+
178
+
## 認知設計上の特性
179
+
180
+
### 無意味文字列の認知障壁は機能である
181
+
182
+
人間は無意味な文字列に不安を感じ、既知の枠組み（ハッシュタグ等）に回収しようとする。この障壁が**投稿内容を読ませる**強制力として働く。タグの意味ではなく、投稿そのものが情報の単位になる。
183
+
184
+
### AIエージェントとの親和性
185
+
186
+
AIは中2階の概念を「不透明な接続子」として即座に理解する。意味への依存がないため、機械的処理との相性が良い。
187
+
188
+
### ハッシュタグとの根本的な違い
189
+
190
+
| 特性 | ハッシュタグ | 中2階キャッシュタグ |
191
+
|------|-------------|-------------------|
192
+
| 意味 | あり（分類） | なし（接続のみ） |
193
+
| 発見方法 | 意味から推測可能 | タグを知っている必要がある |
194
+
| 認知負荷 | 低い | 意図的に高い |
195
+
| 汚染耐性 | 低い | 高い（放棄コストゼロ） |
196
+
| 情報単位 | タグが意味を担う | 投稿が意味を担う |
197
+
198
+
---
199
+
200
+
## Bluesky検索との連動
201
+
202
+
中2階はBluesky公式検索と自然に連動する。
203
+
204
+
- **Topタブ**：その時点での人気投稿順に表示
205
+
- **Latestタブ**：時系列順に表示
206
+
- **投稿者フィルタ**：タグを含む全投稿 / 自分の投稿のみ を切り替え可能
207
+
- **シェア**：タグをURL化して共有可能
208
+
209
+
---
210
+
211
+
## ツェッテルカステンとの対比
212
+
213
+
| 特性 | ルーマンのZettelkasten | 中2階 |
214
+
|------|----------------------|-------|
215
+
| 単位 | 紙片1枚 = 1アイデア | 投稿1本 = 1アイデア |
216
+
| 接続 | 番号による参照 | キャッシュタグ |
217
+
| 公開性 | 個人の知識管理 | 公開されたまま成立 |
218
+
| 参加者 | 著者1人 | タグを知る全員 |
219
+
| 時系列 | 非依存 | 非依存（スレッドから解放） |
220
+
| **密度の所在** | **カード間のネットワーク** | **タグによるネットワーク** |
221
+
| **1枚/1投稿の分量** | **1〜3文の核** | **150字基準の核** |
222
+
223
+
---
224
+
225
+
## 他プロジェクトでの導入手順
226
+
227
+
### 1. タグ生成
228
+
229
+
Cashtag Anchor Generator（付属HTML）または以下のルールで手動生成する。
230
+
231
+
- 英字で始まる5文字のランダム英数字列
232
+
- 既存の英単語・略語・金融シンボルと重複しないことを確認
233
+
- 同一プロジェクト内で重複しないことを確認
234
+
235
+
### 2. チャンネル設計
236
+
237
+
- まず1〜3個のチャンネルから始める
238
+
- チャンネル名（タグ）とテーマの対応表を作成する
239
+
- テーマは厳密な分類ではなく「入口」として機能させる
240
+
241
+
### 3. 投稿ルールの周知
242
+
243
+
参加者に以下を伝える。
244
+
245
+
1. トップポストは末尾にタグ、サポートポストは先頭にタグ
246
+
2. タグは投稿内容を分類するものではなく、接続するものである
247
+
3. つけたいときにつける。義務ではない
248
+
4. 同じタグの投稿はBluesky検索で一覧できる
249
+
5. 1投稿は核だけを書く。論証の展開はしない（v2.1追加）
250
+
251
+
### 4. 運用開始後
252
+
253
+
- 汚染が起きたらタグを放棄して新規生成する
254
+
- チャンネルは必要に応じて自由に増減する
255
+
- スレッドは使わない。1投稿1アイデアの原則を守る
256
+
257
+
---
258
+
259
+
## 将来の技術展望
260
+
261
+
### 短期：クライアント側UI自動化
262
+
263
+
開発者Erlend、nichothらによる提案。投稿UIでのタグ挿入自動化。
264
+
265
+
### 中長期：ATプロトコルネイティブ実装
266
+
267
+
Makeworldの提案によるLexicon定義のレコード型とフィードジェネレータ。キャッシュタグの転用ではなく、プロトコルレベルでの中2階サポート。
268
+
269
+
---
270
+
271
+
## AI支援者向けインストラクション（カスタムインストラクション用）
272
+
273
+
以下をClaude ProjectsやChatGPTのカスタムインストラクションに貼り付けて使用できる。
274
+
275
+
```
276
+
## 中2階（Mezzanine）技法
277
+
278
+
ユーザーは中2階（Mezzanine）情報ネットワーキングシステムを運用している。
279
+
280
+
### 基本ルール
281
+
- キャッシュタグ（$+5文字の英数ランダム列）を不透明な接続子として使う
282
+
- タグに意味はない。指し示すが、意味しない（opaque connector）
283
+
- トップポスト：本文末尾にスペース1つ+タグ（例：「本文。 $xS0yV」）
284
+
- サポートポスト：先頭にタグ（例：「$xS0yV 補足情報」）
285
+
- 出典リンク付きトップポスト：本文→空行→URL+スペース+タグ（タグがURLに視覚的に紛れるカモフラージュ効果）
286
+
- 出典リンク付きサポートポスト：先頭にタグ→本文→空行→URL
287
+
- 1投稿1アイデア。スレッドは使わない
288
+
- タグは義務ではなく選択。つけたいときにつける
289
+
- 汚染されたタグはコストゼロで放棄し新規生成する
290
+
291
+
### ルーマン・メソッド（核化原則）
292
+
- 投稿には思考の核だけを書く。論証の展開・接続構造は書かない
293
+
- 150字基準。300字を使い切る必要はない
294
+
- 旗を立てる、地図は渡さない（着想の存在を示すが、分析の筋道は渡さない）
295
+
- サポートポストは前の投稿の論理的な「次のステップ」にしない
296
+
- 例外：ファクト投稿、仕様告知、創作、布教目的は300字フル活用可
297
+
298
+
### チャンネル一覧（必要に応じて更新）
299
+
- $cT7aZ：Anchor（中2階基幹・メタ情報）
300
+
- $ATOPR：AT Protocol（技術コミュニティ向け）
301
+
- $sT3m0：STEM（AI・言語学・NP・技術）
302
+
- $L1f3x：Life（日常・小話・文具）
303
+
- $cLt7r：Culture（読書・視聴・エンタメ・掌編）
304
+
公式タグは半透明（semi-transparent）。個人チャンネルは完全opaqueを推奨。
305
+
（ユーザーが新チャンネルを追加したらここに追記する）
306
+
307
+
### 投稿作成時の注意
308
+
- ハッシュタグ的な分類思考で扱わない
309
+
- タグの「意味」を推測して内容を制限しない
310
+
- チャンネルテーマはゆるい入口であり、ドリフトを許容する
311
+
- 投稿文の校正時はタグの位置（末尾/先頭）を保持する
312
+
- 投稿文が論証の筋道を復元可能にしていないか確認する
313
+
```
314
+
315
+
---
316
+
317
+
## ライセンス
318
+
319
+
中2階の概念と運用方法は自由に使用・改変・再配布できる。帰属表示は歓迎するが必須ではない。