moja.blue
ATProto-native Lexicon definitions for Mezzanine, an information networking system using opaque cashtag connectors on Bluesky.
Add English spec summary, move Japanese spec to docs/
+385
-244
+2
-1
README.md
+2
-1
README.md
···
31
31
## Mezzanine Spec
32
32
33
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)
34
+
- [mezzanine-spec-v2.1.1.md](./mezzanine-spec-v2.1.1.md) (English summary)
35
+
- [docs/mezzanine-spec-v2.1.1-ja.md](./docs/mezzanine-spec-v2.1.1-ja.md) (full spec, Japanese)
35
36
- [Nightflight blog](https://plurality.leaflet.pub) (canonical)
36
37
37
38
## Channel Tags
+319
docs/mezzanine-spec-v2.1.1-ja.md
+319
docs/mezzanine-spec-v2.1.1-ja.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階の概念と運用方法は自由に使用・改変・再配布できる。帰属表示は歓迎するが必須ではない。
+64
-243
mezzanine-spec-v2.1.1.md
+64
-243
mezzanine-spec-v2.1.1.md
···
1
-
# 中2階（Mezzanine）情報ネットワーキング技法 仕様書
1
+
# Mezzanine Specification
2
2
3
-
**Version:** 2.1
3
+
**Version:** 2.1.1
4
4
**Date:** 2026-03-04
5
5
**Author:** Nighthaven
6
6
7
-
**v2.1 変更点：** ルーマン・メソッド（核化原則）の導入。投稿密度の設計原則を追加し、公開投稿における知的財産保護と情報密度の最適化を明文化した。
7
+
This is a summary of the Mezzanine specification for ATProto developers. The full specification (Japanese) is available at [docs/mezzanine-spec-v2.1.1-ja.md](./docs/mezzanine-spec-v2.1.1-ja.md).
8
8
9
9
---
10
10
11
-
## 概要
11
+
## What is Mezzanine?
12
12
13
-
中2階（Mezzanine）は、Blueskyのキャッシュタグ（cashtag: `$` + 英数字）を**無意味なランダム文字列のアンカー**として転用する情報ネットワーキングシステムである。従来のスレッド構造を解体し、投稿の自律性と有機的接続を両立させる。
13
+
Mezzanine is an information networking system built on Bluesky's cashtag feature (`$` + alphanumeric string). It repurposes random character strings as **opaque connectors** — they point without signifying.
14
14
15
-
ハッシュタグが意味による分類を行うのに対し、中2階のタグは**不透明な接続子（opaque connector）**として機能する。指し示すが、意味しない。
15
+
Where hashtags classify by meaning, Mezzanine tags connect without meaning. The post itself carries the information, not the tag.
16
16
17
-
理論的には、ルーマンのツェッテルカステンの社会化版であり、ウイルス型ではなく周波数型の情報流通モデルで動作する。
17
+
Theoretically, Mezzanine is a socialized Zettelkasten (Luhmann method), operating on a frequency model rather than a viral one.
18
18
19
19
---
20
20
21
-
## 技術仕様
21
+
## Tag Specification
22
22
23
-
### キャッシュタグの制約
23
+
- **Prefix:** `$` (dollar sign)
24
+
- **Characters:** A-Z, a-z, 0-9
25
+
- **Length:** 5 characters recommended (3–5 valid range)
26
+
- **First character:** must be alphabetic
27
+
- **Case:** insensitive
28
+
- **Digit requirement:** must contain at least one digit to avoid collision with stock ticker symbols
29
+
- **Combinations:** ~45 million at 5 characters
24
30
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. 汚染（他者が無関係な文脈で同じタグを使用）が発生したら、コストゼロでタグを放棄し新規生成する
31
+
Tags must be **meaningless**. Avoid English words, abbreviations, or existing financial cashtags. If a tag gets polluted (used by others in unrelated contexts), abandon it and generate a new one at zero cost.
40
32
41
33
---
42
34
43
-
## 投稿フォーマット
44
-
45
-
### トップポスト（主投稿）
35
+
## Post Format
46
36
47
-
本文の末尾にスペース1つ + タグを置く。
37
+
**Top post** (entry point): tag at the end of the body.
48
38
49
39
```
50
-
本文本文本文本文。 $xS0yV
40
+
Your post body goes here. $xS0yV
51
41
```
52
42
53
-
### サポートポスト（補助投稿）
54
-
55
-
タグを先頭に置く。
43
+
**Support post** (supplementary): tag at the beginning.
56
44
57
45
```
58
46
$xS0yV
59
-
補足情報や関連する内容をここに書く。
47
+
Supplementary content goes here.
60
48
```
61
49
62
-
### 出典リンク付きフォーマット
63
-
64
-
出典URLを1つ掲載する場合、以下のフォーマットを使用する。
65
-
66
-
#### トップポスト + 出典リンク
67
-
68
-
本文の後に1行空け、最終行にURL + スペース + タグを置く。
50
+
**Top post with source link**: body, blank line, URL + space + tag on the last line. The tag visually blends into the URL's trailing alphanumeric characters — visual camouflage by design.
69
51
70
52
```
71
-
本文本文本文本文。
53
+
Your post body goes here.
72
54
73
55
bsky.app/profile/example/post/xxxx $xS0yV
74
56
```
75
57
76
-
タグがURLの末尾に視覚的に紛れる効果がある。URL末尾の英数字列とキャッシュタグの見た目が近いため、タグの存在感が消える——**視覚的カモフラージュ**として機能する。中2階を知る者はタグをスキャンするため視認性に問題はなく、タグを目的外利用だと認識する層には認知コストが上がる。「知っている人だけがアクセスする」設計思想と一致する。
77
-
78
-
#### サポートポスト + 出典リンク
79
-
80
-
先頭にタグ、本文の後に1行空けてURLを置く。
58
+
**Support post with source link**: tag first, body, blank line, URL.
81
59
82
60
```
83
61
$xS0yV
84
-
補足情報や関連する内容をここに書く。
62
+
Supplementary content goes here.
85
63
86
64
bsky.app/profile/example/post/xxxx
87
65
```
88
-
89
-
### フォーマット判定基準
90
-
91
-
- トップポスト：そのチャンネルの「入口」となる独立した投稿
92
-
- サポートポスト：既存の文脈に接続する投稿、補足、反応
93
66
94
67
---
95
68
96
-
## ルーマン・メソッド（核化原則）— v2.1で追加
97
-
98
-
### ルーマンのカードに立ち返る
99
-
100
-
中2階はルーマンのツェッテルカステンの社会化版を標榜する。ルーマンのカードの実物を確認すると、1枚のカードは文字の壁ではない。典型的には1〜3文の短い記述、断片的で、余白が多く、カードの相当な面積を参照番号とリンク記号が占める。
69
+
## Kernification (Luhmann Method)
101
70
102
-
**密度はカード単体ではなく、カード間のネットワークで生まれる。**
71
+
Luhmann's actual index cards were not walls of text. They were 1–3 sentences, fragmentary, with generous whitespace. **Density emerges from the network between cards, not from individual cards.**
103
72
104
-
中2階の投稿も同じである。1投稿の密度を上げるのではなく、タグによるネットワークが密度を担う。
73
+
Mezzanine follows the same principle:
105
74
106
-
### 核化原則（Kernification）
75
+
1. **Post only the kernel**: name a concept, capture a phenomenon, pose a question. Do not develop arguments or show logical connections.
76
+
2. **150-character baseline**: no need to fill the 300-character limit. If the kernel communicates in ~150 characters, that is enough. The tag network carries the rest.
77
+
3. **Plant flags, not maps**: a public post signals "this idea exists." The logic connecting flags belongs in the author's head and in their papers.
78
+
4. **Protect by pruning**: research questions and analytical frameworks are the first candidates for removal from public posts.
79
+
5. **Support post independence**: support posts must not be logical "next steps" of previous posts. Each post must stand as an independent kernel.
107
80
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
-
- 分析フレームワークの適用範囲や射程が見えていないか？ → その部分を削る
81
+
**Exceptions** (full 300 characters permitted): fact listings, spec announcements, creative writing, outreach/explanatory posts.
132
82
133
83
---
134
84
135
-
## チャンネル運用原則
136
-
137
-
### 基本思想
138
-
139
-
- **フロー > ストック**：分類装置ではない。流れの中に置く
140
-
- **タグは選択であり義務ではない**：つけたいときにつける
141
-
- **チャンネルのテーマは入口であり、内容のドリフトを許容する**
142
-
- **放棄コストゼロ**：汚染されたら新しいタグを作ればいい
143
-
144
-
### 投稿時の設定
145
-
146
-
- **引用ポスト無効化**を推奨（中2階投稿に対して）
147
-
- **メンション無効化**を推奨（中2階投稿に対して）
148
-
- これによりシステムの完全性を維持する
149
-
150
-
### チャンネル構成
85
+
## Channel Design
151
86
152
-
#### 三分類の設計思想
87
+
Human posts divide into three kinds: knowing (STEM), living (Life), experiencing (Culture). Finer divisions create a classification apparatus. Coarser divisions are meaningless. Three is the critical threshold.
153
88
154
-
人類の投稿は3つに分かれる。知ること（STEM）、生きること（Life）、味わうこと（Culture）。これ以上細かく分けると分類装置になる。これ以上粗くすると意味がない。3が臨界点である。
89
+
Official channels use **semi-transparent tags** — not fully opaque, with the theme faintly showing through. This lowers the cognitive barrier for newcomers. Fully opaque tags are recommended for personal channels.
155
90
156
-
公式チャンネルはこの三分類に、基幹タグと技術コミュニティ向けタグを加えた5チャンネルで構成する。
91
+
**Official channels:**
157
92
158
-
#### 半透明タグ（semi-transparent tag）
93
+
- `$cT7aZ` — Anchor (system meta)
94
+
- `$ATOPR` — AT Protocol ecosystem
95
+
- `$sT3m0` — STEM
96
+
- `$L1f3x` — Life
97
+
- `$cLt7r` — Culture
159
98
160
-
公式チャンネルのタグは完全ランダムではなく、テーマが薄く透ける程度の文字列を採用する。完全opaque（不透明）と完全transparent（透明）の中間——半透明タグと呼ぶ。
99
+
**Operating principles:**
161
100
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
-
これらは公式チャンネルであり、誰でも自由に個人チャンネルを作成できる。
101
+
- Flow over stock. This is not a classification apparatus.
102
+
- Tags are optional, not mandatory.
103
+
- Channel themes are entry points. Content drift is welcome.
104
+
- Polluted tags are abandoned and regenerated at zero cost.
175
105
176
106
---
177
107
178
-
## 認知設計上の特性
108
+
## Cognitive Design
179
109
180
-
### 無意味文字列の認知障壁は機能である
110
+
**The cognitive barrier of meaningless strings is a feature.** Humans feel anxiety about meaningless strings and try to map them onto known frameworks (hashtags). This barrier forces readers to engage with the post content itself — the post, not the tag, becomes the unit of information.
181
111
182
-
人間は無意味な文字列に不安を感じ、既知の枠組み（ハッシュタグ等）に回収しようとする。この障壁が**投稿内容を読ませる**強制力として働く。タグの意味ではなく、投稿そのものが情報の単位になる。
112
+
**AI affinity:** AI agents immediately grasp "opaque connectors" as the correct frame. No semantic dependency means clean machine processing.
183
113
184
-
### AIエージェントとの親和性
114
+
**Hashtag vs. Mezzanine cashtag:**
185
115
186
-
AIは中2階の概念を「不透明な接続子」として即座に理解する。意味への依存がないため、機械的処理との相性が良い。
187
-
188
-
### ハッシュタグとの根本的な違い
189
-
190
-
| 特性 | ハッシュタグ | 中2階キャッシュタグ |
191
-
|------|-------------|-------------------|
192
-
| 意味 | あり（分類） | なし（接続のみ） |
193
-
| 発見方法 | 意味から推測可能 | タグを知っている必要がある |
194
-
| 認知負荷 | 低い | 意図的に高い |
195
-
| 汚染耐性 | 低い | 高い（放棄コストゼロ） |
196
-
| 情報単位 | タグが意味を担う | 投稿が意味を担う |
116
+
- Hashtag: carries meaning (classification). Discoverable by guessing. Low cognitive load. Low pollution resistance.
117
+
- Mezzanine tag: carries no meaning (connection only). Requires knowing the tag. Intentionally high cognitive load. High pollution resistance (zero abandonment cost).
197
118
198
119
---
199
120
200
-
## Bluesky検索との連動
121
+
## Bluesky Search Integration
201
122
202
-
中2階はBluesky公式検索と自然に連動する。
123
+
Mezzanine works natively with Bluesky's search:
203
124
204
-
- **Topタブ**：その時点での人気投稿順に表示
205
-
- **Latestタブ**：時系列順に表示
206
-
- **投稿者フィルタ**：タグを含む全投稿 / 自分の投稿のみ を切り替え可能
207
-
- **シェア**：タグをURL化して共有可能
125
+
- **Top tab**: popular posts with the tag
126
+
- **Latest tab**: chronological
127
+
- **Author filter**: all posts with tag / my posts only
128
+
- **Sharing**: tags can be URL-encoded and shared directly
208
129
209
130
---
210
131
211
-
## ツェッテルカステンとの対比
132
+
## Future: ATProto-Native Implementation
212
133
213
-
| 特性 | ルーマンのZettelkasten | 中2階 |
214
-
|------|----------------------|-------|
215
-
| 単位 | 紙片1枚 = 1アイデア | 投稿1本 = 1アイデア |
216
-
| 接続 | 番号による参照 | キャッシュタグ |
217
-
| 公開性 | 個人の知識管理 | 公開されたまま成立 |
218
-
| 参加者 | 著者1人 | タグを知る全員 |
219
-
| 時系列 | 非依存 | 非依存（スレッドから解放） |
220
-
| **密度の所在** | **カード間のネットワーク** | **タグによるネットワーク** |
221
-
| **1枚/1投稿の分量** | **1〜3文の核** | **150字基準の核** |
134
+
This repository contains Lexicon definitions for moving Mezzanine from a text convention to a protocol-native system. See [README.md](./README.md) for the phased architecture.
222
135
223
136
---
224
137
225
-
## 他プロジェクトでの導入手順
226
-
227
-
### 1. タグ生成
228
-
229
-
Cashtag Anchor Generator（付属HTML）または以下のルールで手動生成する。
230
-
231
-
- 英字で始まる5文字のランダム英数字列
232
-
- 既存の英単語・略語・金融シンボルと重複しないことを確認
233
-
- 同一プロジェクト内で重複しないことを確認
138
+
## License
234
139
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階の概念と運用方法は自由に使用・改変・再配布できる。帰属表示は歓迎するが必須ではない。
140
+
Mezzanine concepts and methods are free to use, modify, and redistribute. Attribution is appreciated but not required.