Squalk登場 Nostr上に古典的掲示板を再現

Nostr上に古典的な掲示板を再構築する開放型の掲示板基盤「Squalk」が公開された。 利用者が鍵対を持ち、投稿が署名付き事象として複数のリレーに保持される構造を採用する。 Lobsters上の github.com by daniele の報告では、開発の動機が古典的な掲示板への回帰にあるとしている。

I miss classic forums: slow, asynchronous threads that stay readable and searchable for years, instead of knowledge dissolving into chat scrollback.

即時対話の流れに知識が埋もれる現状に対し、非同期の糸状対話を長期間読み書き可能にする狙いだ。 掲示板自体は特定の専用保存庫を持たず、リレーが保持する資料への表示層として動作する。 2026-09-21に資料が公開され、技術者層の注目を集めている。

Nostr上に古典的掲示板を再現

SqualkはNostrを土台とする掲示板基盤である。 NIP-29とNIP-7Dを実装し、集団管理と糸状対話を開放型通信規格で処理する。 部屋に相当する単位はNIP-29で定める集団であり、糸状対話はNIP-7Dの事象として表す。

身元管理は鍵対に基づく。 投稿は秘密鍵で署名され、事象としてリレーに配布される。 利用者は特定の運営者の保存庫に縛られず、互換性のあるリレー間で資料を移動できる。

開発者はPyramidを推奨構成として挙げている。 PyramidはNIP-29に対応した個人用リレーと、画像などの保存に使うBlossom供与機を一体で備える。 Squalk自体は表示と操作を担い、保存と配布を外部の互換基盤に委ねる分離が特徴だ。

個人が基盤を運用する流れは、Vulkan Videoエンコード、Intel Alchemist GPUで復活 が示す自律的な環境整備とも重なる。 特定の事業者に依存しない運用を選ぶ技術者の層が拡大している。

所有しない掲示板という設計思想

Squalkの設計は「掲示板は資料への見方である」と要約できる。 運営者が投稿本文を自前の保存庫に抱え込まない。 リレーが保持する署名付き事象を読み出し、部屋や糸状対話として整形する。

この分離は移転可能性を高める。 リレーの変更や複数化があっても、鍵対と署名が同一である限り投稿の帰属は保たれる。 運営者の交代や基盤の停止があっても、資料自体は別の経由で参照できる余地が残る。

一方で可用性は外部基盤に依存する。 個人用リレーの保守やBlossom供与機の運用が滞れば、表示に欠損が生じる。 分散化は管理の消失ではなく、管理の所在を運営者に返す仕組みだと理解する必要がある。

大規模な言語間移植で基盤の独立性が議論された事例として、Bun、Claude Fable 5で53万行をZig→Rust移植 がある。 開放型部品の組み合わせで全体を作る発想は、今回の掲示板設計と共通する。

単独と複数運営両方に対応する構成

Squalkはsimpleとfullという二つの動作形態を持つ。 simpleは単一の掲示板を公開する形態である。 fullは複数の掲示板を同一の導入で扱う形態である。

管理者はsimpleからfullへ運用中に移行できる。 小規模な集団で開始し、必要に応じて部屋を増やす段階的な拡張が可能だ。 部屋ごとの右側欄には即時対話欄が備わり、短いやり取りと長い議論を使い分けられる。

この二層構造は、古典的な掲示板と対話欄の併設に近い。 記録に残すべき議論は糸状対話に蓄積する。 調整や雑談は右側欄で処理し、本体の可読性を損なわない運用が想定されている。

携帯型や据置型の利用環境が多様化する中で、Juno Tab 4、Linuxタブレット2機種発表 Core i3とCore Ultra搭載 のように閲覧端末の選択肢も広がっている。 表示層に徹した掲示板は、端末を問わない参照に適した構造だ。

環境変数だけで完結する設定体系

Squalkの設定はすべてPUBLIC_で始まる環境変数でおこなう。 読者は閲覧器側で読まれる値を複製した雛形に記入する。 SvelteKitの仕組みにより、開発時と構築時で読み込む文書が切り替わる。

必須項目はPUBLIC_RELAY_URLである。 NIP-29に対応したリレーのWebSocket宛先を指定する。 simple形態ではPUBLIC_GROUP_IDも必須となり、単一掲示板の集団識別子を示す。

任意項目としてPUBLIC_MODEがある。 既定値はsimpleであり、fullを指定すると複数部屋運用になる。 PUBLIC_TITLEは上部帯の表示名であり、空欄時は集団名に退行する。

PUBLIC_JOINCODEは参加要求が拒否された場合に招待符号欄を示すための旗である。 符号で入場を制限するリレーでの利用を想定している。 PUBLIC_LABELSは投稿時に付与する分類であり、bugやfeatureやquestionなどを comma で区切って列挙する。

外観調整としてPUBLIC_ACCENT_COLORとPUBLIC_SECONDARY_COLORがある。 主要色と副次色を上書きし、停留時の色合いは自動で導出される。 先頭の#は注釈と解釈されるため、引用符で囲む扱いが定められている。

検索と描画処理を支える周辺機能

検索欄の表示はPUBLIC_SEARCHで制御する。 有効化にはNIP-50の検索に対応したリレーが必要である。 長期間の蓄積を再利用する古典的掲示板の目的に直結する機能だ。

画像などの保存はPUBLIC_BLOSSOM_URLで制御する。 Blossom供与機の宛先を指定し、未設定時は保存機能が無効になる。 投稿本文と添付資料の保存先を分けることで、リレーへの負荷集中を避けている。

描画処理にはPUBLIC_SSRと関連変数が用意されている。 PUBLIC_SSRを有効にすると頁を供与機側で描画し、巡回可能な文書と正確な404応答を得られる。 構築物は静的束ではなくNode向けの生成物になる。

PUBLIC_SSR_WARMは閲覧器側の移動ごとに供与機側の取得と蓄積を求める旗である。 後の再読込や共有接続や巡回時の応答を温かい状態で返す狙いがある。 供与機側で余分な問い合わせが一つ増える代償と引き換えになる。

PUBLIC_SSR_CACHE_FRESHは供与機側の写像をそのまま返す秒数であり、既定値は300である。 PUBLIC_SSR_CACHE_STALEは写像を裏側で更新しつつ即時応答できる期限であり、既定値は21600である。 辺縁の蓄積機構にも同じ値が受け渡される設計だ。

集中管理型との相違と残された課題

集中管理型の掲示板は、利用者登録と投稿保存と表示を一体で担う。 運営者の保存庫が唯一の正本となり、移転や保存は運営者の提供機能に依存する。 Squalkは登録と保存と表示を分解し、鍵対と署名と互換リレーで代替する。

この分解は検閲耐性と可搬性を高める。 特定の表示層が停止しても、資料がリレーに残る限り別の表示層で再構成できる。 利用者は鍵対を保持する限り、別の運用への移動が容易だ。

課題は迷惑対策と運用負荷にある。 開放型の身元管理では、禁止や制限の執行を集団管理とリレー側の規則に委ねる必要がある。 NIP-29の集団運営機能がどこまで細かな調整を担えるかは、実運用の検証を要する。

資料の所在が分散するため、消失対策の設計も運営者に委ねられる。 個人用リレーの待避や複写、Blossom供与機の冗長化が不可欠になる。 自由度の拡大と運用責任の増大は表裏一体である。

編集部の見解

短期的には、NIP-29対応リレーとBlossomを備えた個人が試験導入を進めると見る。小規模な技術者集団が設定の容易さを検証する動きが先行する。運用報告の蓄積が導入手順の洗練を促すと評価する。

長い目では、署名付き事象の蓄積が検索可能な知識基盤になると見る。移転可能な記録が集団の記憶を特定の運営者に依存させない点は重い。書き込みの可搬性が場の寿命を延ばすと評価する。

残る論点は司法的執行と迷惑対策の所在である。鍵対に基づく身元管理が荒らしへの対処をどこまで担えるかは未検証だ。開放性と秩序の両立にどのような調整が必要か、運用を通じた検証が問われている。

参考

• 「Squalk: an old-school forum engine built on Nostr (NIP-29 groups, NIP-7D threads)」, by github.com by daniele — Lobsters, 2026-09-21T14:44:12.000Z (ARR)
• 元記事URL: https://github.com/dtonon/squalk