国際SMM

Nostr

プラットフォーム · この詳細解説は、プラットフォーム自身と プラットフォーム自身と補助ツールのページ。

関連項目： カードの読み方 и 出典と方法について.

概要

Nostr はプラットフォームではなく プロトコル である。名称は Notes and Other Stuff Transmitted by Relays の略で、«リレー経由で 伝達されるノートおよびその他のもの» という意味になる。サイト nostr.com はこれを «誰も所有せず、誰も支配しない自由で開かれたネットワーク» と説明している。

仕組みは単純で、その上に残りのすべてが載っている。まず リレー — メッセージを保存し配信するサーバーがある。次に クライアント — 人々が読み書きするためのアプリケーションがある。そして 鍵 がある。 公開鍵はユーザー名として、秘密鍵はパスワードとして働く。あなたの アイデンティティに対する権利を与えるのは企業ではなく鍵そのもので ある。アイデンティティがアプリケーションでは なく鍵に属するため、プロフィール、フォロワー、投稿を保ったまま クライアントを移り変わることができる。

技術的には、すべてが単一の種類のオブジェクトに帰着する。プロトコルの 基本文書はこう述べている。存在するオブジェクトの種類は «イベント» (event) ただ一つであり、署名と鍵は secp256k1 曲線上の Schnorr 方式を 用いる。リレーは外部に websocket のエンドポイントを公開し、 クライアントはそこへ 3 種類のメッセージを送る。投稿のための EVENT、 抽出条件を購読するための REQ、その購読を閉じるための CLOSE である。

本カタログにとって、これは次を意味する。Nostr には所有者も、単一の 利用者層も、広告管理画面も、モデレーション規則も、支払いプログラムも ない。以下では、その代わりに何があるのかを見ていく。

利用者層

Nostr の利用者数という数値は存在しないし、通常の意味では存在し得ない。 利用者を数える中央サーバーがないためである。あるのは多数の独立した リレーであり、それぞれは自分のところの利用者しか見えない。

間接的に判断できるのは個別のリレーからだけである。nostr.com の クライアントは既定で 6 つのリレーに接続し、その一覧を画面上に そのまま表示している。relay.nostr.com、relay.damus.io、nos.lol、 nostr.bitcoiner.social、nostr.mom、relay.snort.social である。リレーの一覧は外部サービスの Nostr.watch で、クライアントの 一覧は nostrapps.com で見るようプロジェクトは勧めている (リレーについてのページ、 クライアントについてのページ)。

言語別・国別の内訳はなく、あり得ない。プロトコルは利用者について そうした情報を保持しないからである。プロフィールは既定では 名前、説明、画像 だけを含む。

始め方

通常の意味での登録はない。アカウントとはアプリケーションが生成する 鍵のペアである。メールの確認も、電話番号も、申請の審査もない。

ここから、プロジェクト自身が警告する最大のリスクが生じる。 秘密鍵はアカウントへの完全な権限を与える。それがあれば、あなたの 名前で投稿し、プロフィールを変更し、メッセージを送ることができる。 鍵を失い、控えもない場合、«パスワードをお忘れですか» のボタンは 存在しない。プロジェクトの実践的な 助言はこうである。秘密鍵を手当たり次第にあらゆるアプリケーションへ 貼り付けないこと。ブラウザーの署名拡張機能かリモート署名機能のほうが 安全である。

«認証バッジ» に似た検証可能な名前を得ることはできる。プロトコルの 別の文書が、鍵とドメインの結び付けを記述している。クライアントは プロフィールから 名前@ドメイン の形式のアドレスを取り、 https://ドメイン/.well-known/nostr.json?name=名前 に問い合わせ、 得られた公開鍵を投稿の作者の鍵と照合する。 企業にとってはこれこそが、そのアカウントが本当に自社のものだと 裏付ける方法である。裏付けを与えるのはモデレーターの判断ではなく、 ドメインの管理権である。

法人用のアカウントは別に用意されていない。通常のアカウントという ものがそもそもないのと同じである。Nostr における企業の存在とは、 自社ドメインに結び付けられた鍵であり、望むなら自前のリレーである。

投稿できるもの

形式はイベントの «種別» によって定まり、種別は個別の文書 — NIP (Nostr Implementation Possibilities) に記述されている。その一覧は 公開リポジトリで管理されており、とりわけ次を含む。短いノートと 議論のスレッド、長文記事、画像と動画、ライブ配信と «スペース»、 アンケート、カレンダーの予定、ウィキ、トレント、リスト、ブックマーク、 引用である (NIP の一覧)。

長さやサイズの制限はプロトコルにはなく、リレーにある。そしてリレーは それを公表する義務を負う。リレー情報についての文書は次の項目を 記述している。max_message_length — 受信する JSON のバイト単位の 上限 (事実上イベントの大きさの上限でもある)、max_content_length — 本文欄の文字数の上限、max_event_tags — タグ数の上限、 max_subscriptions — 一つの接続における同時購読数、max_limit — 一回の問い合わせへの応答に含まれるイベント数の 上限。

実際にはこう見える。リレー relay.damus.io は確認日時点で メッセージ上限 1 000 000 バイト、購読 200 件、抽出上限 500 イベント を公表している。リレー nos.lol は 131 072 バイト、購読 20 件、同じく 500 イベント、 リレー relay.nostr.com は 131 072 バイト、購読 200 件、500 イベント である。これらの数値は各リレーに 個別に属するもので、別のリレーでは別の値になる。

内容についての禁止事項はプロトコルにはない。あるのは技術的な標識 である。ある文書は繊細な内容への印付けを、別の文書はイベントへの 通報を、三つ目は削除の要求を記述している。 «要求» という語に注意されたい。Nostr における削除はリレーへの依頼で あって、保証ではない。何を受け入れ何を保存するかはリレーの所有者が 決める。

成長のさせ方

アルゴリズムによるフィードはプロトコルにはない。利用者に何を見せるかは クライアントが決め、どのイベントを渡すかはリレーが決める。nostr.com のクライアントはそれをそのまま示している。その画面にはフィードの 選択肢として «フォロー中»、«グローバル»、«自分» があり、その下に 接続中のリレーの一覧がある。

ここから実践的な帰結が生じ、プロジェクト自身がそれを説明している。 Nostr が遅い、あるいは空だと感じられるなら、原因はリレーにあるかも しれない。一部のリレーは速く信頼できるが、一部は停止して応答しない。 良いリレーをいくつか追加すると大きく変わる。 Nostr における成長とは、何よりもまず、実際に読者のいるリレーへ投稿する ことである。

広告管理画面は存在しない。プロトコルには表示を販売するプラットフォームも、 それを計測する仕組みもない。組み込みの統計もない。それに最も近いのは リレーが可能な範囲でおおよそ実行する COUNT の問い合わせ である。

スパム対策としてプロトコルが提示する手段は変わっている。 プルーフ・オブ・ワークについての文書は、新しいイベントに対して 指定された計算量を要求することをリレーに許している。 第二の手段は金銭である。一部のリレーは有料であり、それがスパムを 減らす。リレーの維持には金がかかり、利用者の側には行儀よく振る舞う 理由ができるからである。

収益化への道

プラットフォームがない以上、プラットフォームからの支払いもない。 その代わり、人と人との直接の支払いがあり、それはプロトコル自体に 記述されている。

仕組みは «ザップ» (zap) と呼ばれ、Lightning ネットワークを通じた 支払いである。プロトコルの文書は 2 種類のイベントを導入している。 9734 — ザップの要求、すなわち支払う側が受取人のウォレットへ 請求書を求める働きかけ。9735 — 領収、すなわち請求書が支払われた ことを示す受取人のウォレットの確認である。 流れはこうである。クライアントは 受取人のプロフィールから支払い エンドポイントのアドレスを取り、それが Nostr に対応していることを 確認し、そこへ署名済みの要求を送って請求書を受け取る。支払いのあと、 ウォレットが領収を公開する。 領収の意味も同じ文書で説明されている。それによってクライアントは 支払いをフィード上にそのまま表示できる。楽しみのためでもあり、 スパム対策の手段としてでもある。

この方式にプラットフォームの手数料はない。金はウォレットから ウォレットへ直接動く。しかしプラットフォームの保証もない。支払いの 到達に責任を負うのは Lightning ネットワークと、あなたが選んだ ウォレット提供者である。

ザップのほかにも、プロトコルの一覧には金銭に関わる仕組みが含まれる。 集金目標 (zap goals)、バッジ、Cashu ウォレットと «ナットザップ»、 ウォレットのリモート接続、人と人との注文イベントで ある。 そのいずれも、クライアントが望めば実装する。

ツールと自動化

Nostr に «公式 API» がないのは、所有者がいないのと同じ理由による。 プロトコル自体がインターフェースなのである。どんなプログラムでも リレーへ websocket を開いて直接やり取りできる (基本文書)。 開発者キーも、利用申請も、アプリケーションの審査も存在しない。

ツールを作る前に、一覧そのものにある注意書きを読んでおくとよい。 «ここにある NIP はプロトコルのチェックリストではない。いかなる プログラムにも、どれかの NIP を実装する義務はない。各アプリケーションは 自分の目的に必要な部分集合を 選ぶ»。 つまり、ある機能が記述されているというだけの理由でそれを当てにしては ならない。個々のリレーがそれに対応しているかを確認する必要がある。 確認の方法は用意されている。リレーは 対応する NIP の一覧、 プログラム名、バージョン、連絡先、自らの利用規約へのリンクを含む文書を HTTP で返す。 上で挙げた 3 つのリレーは同一の構成を公表している。3 つとも strfry というプログラムで動作し、NIP 1、2、4、9、11、28、40、45、70、77 に 対応している。

出来合いの手段としてプロジェクトが挙げるのは、署名用のブラウザー 拡張機能とリモート署名機能、および 自前の署名ツール Pomegranate である。 クライアントとリレーの一覧はプロトコルの外で、nostrapps.com と Nostr.watch において管理されている (クライアントについてのページ、 リレーについてのページ)。

制約とルール

向いている人

プラットフォームの所有者からの独立が重要なプロジェクトに向いている。 アイデンティティは企業ではなく鍵に属し、 アカウントを中央から凍結することはできず、リレーに不満があれば リレーを変えればよい。開発者にも向いている。ネットワークへの接続に アプリケーションキーも承認も要らない。

ビットコインと Lightning に関わるプロジェクトにも向いている。 支払いはザップという形でプロトコルに組み込まれており、 金銭の仕組みの中で最も発達した部分である。

予測可能なリーチと報告が必要なら向かない。ここには測るものがない。 プラットフォームも、統計も、広告管理画面もないからである。大量配信や «宣伝» にも向かない。リレーは料金、ログイン、プルーフ・オブ・ワークを 要求する権利を持ち、説明なしにあなたを遮断できる。そして、組織として サービス提供者との契約が必要な場合にも向かない。プロトコルにはそうした 相手方が存在しない。

データベースの検証済みデータ

詳細解説が依拠する、検証済みの簡潔なデータ。

プラットフォームの概要

プラットフォームは自らを次のように説明している：«Nostr is a free and open-source protocol for social media and other things - controlled by users, not platforms.»

自己説明：プラットフォーム自身による記述であり、独立した評価ではない

出典, 確認済み 2026-07-28

Nostr (Notes and Other Stuff Transmitted by Relays) は、誰も所有せず誰も支配しない自由で開かれたネットワークとして説明されている。リレーがメッセージを保存して配信し、クライアントがその読み書きを可能にする

これはプロトコルであってプラットフォームではない: 所有者も広告管理画面も支払いプログラムも存在しない

出典, 確認済み 2026-07-28

オブジェクトの種類はイベント (event) の 1 つだけ。署名と鍵には secp256k1 曲線上の Schnorr 方式を用いる。リレーは websocket のエンドポイントを公開し、クライアントは公開に EVENT、購読に REQ、購読の解除に CLOSE を送る

プロトコルの基本文書 NIP-01

出典, 確認済み 2026-07-28

始め方

nostr の参入の条件には、規則の単一の所有者がいない: «Nostr (Notes and Other Stuff Transmitted by Relays) is a free and open network that nobody owns or controls»。プロトコルの提案集も、自らについて同じことを断っている: «NIPs listed here are not a protocol checklist. Nothing forces any software to implement any NIP»

引用は逐語、出典の言語は英語。2 つめは NIP 集の README から: https://raw.githubusercontent.com/nostr-protocol/nips/master/README.md。読者にとっての実際的な結論: ネットワーク全体に義務づけられる共通の参入条件は存在しない。条件を定めるのは個々のリレーと個々のアプリであり、それぞれ異なる

出典, 確認済み 2026-08-07

リレーは書き込みを閉じたり、署名によるログインや作業証明を求めたりできる。NIP-11 の制限一覧には «auth_required»、«restricted_writes»、«min_pow_difficulty»、«payment_required» が挙げられている。«Your client should expect that requests exceed these practical limitations are rejected or fail immediately»

引用は原文どおり、出典の言語は英語、出典の綴りをそのまま保っている。プロトコルの水準では申請も招待も審査もない。挙げられているものはすべて個々のリレーの性質であり、リレーにその情報文書を問い合わせれば分かる

出典, 確認済み 2026-08-07

アカウントとアクセス

アカウントとは、プラットフォームの所有者が持つ記録ではなく、鍵のペアである: «Every account has Nostr keys. Your public key is like your username and can be shared with anyone. Your private key is like your password and must be kept safe. These keys give you ownership of your identity, rather than a company owning it for you»

引用は逐語、出典の言語は英語。鍵を得るのに登録も本人確認も承認も必要ない: 鍵のペアは端末上で生成される。任意で使える、検証可能な 名前@ドメイン 形式の名前は NIP-05 として別に記述されている

出典, 確認済み 2026-08-07

アカウントは鍵のペアを持ち、公開鍵がユーザー名、秘密鍵がパスワードとして働く。アイデンティティはアプリではなく鍵に属するため、プロフィールとフォロワーを保ったままクライアントを変えられる

登録もメール確認も申請の審査もない

出典, 確認済み 2026-07-28

秘密鍵をバックアップなしに失った場合、アクセスを回復する手段はない: «パスワードをお忘れですか»というボタンは存在しない

プロジェクトは、秘密鍵をすべてのアプリに貼り付けるのではなく、署名用の拡張機能またはリモート署名を使うよう勧めている

出典, 確認済み 2026-07-28

名前@ドメイン という形式の検証可能な名前。クライアントは https://ドメイン/.well-known/nostr.json?name=名前 を要求し、得られた公開鍵を投稿者の鍵と照合する

企業にとっては、モデレーターの判断ではなくドメインの管理によってアカウントを証明する方法となる

出典, 確認済み 2026-07-28

投稿できる内容

NIP の一覧は、とりわけ次を記述している: 短いノートとスレッド、長文の記事、画像と動画、ライブ配信とスペース、投票、カレンダーイベント、Wiki、トレント、リスト、ブックマーク、引用

NIP の一覧は義務ではない: どの NIP を実装するかをプログラムに強いるものはない

出典, 確認済み 2026-07-28

ここでの収益の仕組み

受け入れの対象。 支払いにフォロワー数、再生数、投稿数の基準はない。zap は Lightning ネットワークを通じて人から人へ直接送られ、条件は受け取り手が lnurl アドレスを持つ財布を用意していることだけである — «Client calculates a recipient's lnurl pay request url from the zap tag on the event being zapped, or by decoding their lud16 field on their profile»

引用は原文どおり、出典の言語は英語。基準はゼロ: NIP-57 はフォロワー数も視聴時間もアカウントの経過期間も求めていない。送れる額の上下限はネットワークではなく受け取り手の財布が «minSendable» と «maxSendable» の項目で定める

出典, 確認済み 2026-08-07

ネットワークの手数料はなく、取る主体も存在しない。お金はプロトコルを通らず受け取り手の財布を経由し、nostr は決済に関与しない。NIP-57 が定めるのは 2 種類のイベント、要求の記録と受領の記録だけである — «9734 is a zap request… 9735 is a zap receipt, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a zap request has been paid»

引用は原文どおり、出典の言語は英語。財布や Lightning ネットワークのノードが独自の手数料を取ることはあるが、それはもはや nostr ではなく、その額は NIP-57 に定められていない。手数料も配分率も出金下限もネットワークにはない。お金を預かる仲介者が存在しないからである

出典, 確認済み 2026-08-07

個人間の支払いは、プロトコルでは Lightning ネットワークを通じた«zap»として記述されている: イベント 9734 が zap の要求、イベント 9735 が受取人のウォレットによる請求書支払いの受領証

この仕組みにプラットフォームの手数料はない: 資金はウォレットからウォレットへ渡る。送達の責任は Lightning ネットワークとウォレット提供者にある

出典, 確認済み 2026-07-28

NIP の一覧には、集金目標 (zap goals)、バッジ、Cashu ウォレットと nutzap、ウォレットのリモート接続、個人間の注文イベントも含まれる

それぞれの仕組みは、クライアントが任意で実装する

出典, 確認済み 2026-07-28

料金

プロトコル自体は料金を取らないが、個々のリレーは取ることができる。NIP-11 は料金のための項目を定めている — «Relays that require payments may want to expose their fee schedules»: «fees»: «admission»（加入料）、«subscription»（«period» 項目を伴う定期課金）、«publication»（公開料、対象となるイベントの種別の指定を伴う）。リレーの制限一覧には «payment_required» という指標がある

引用は原文どおり、出典の言語は英語。数値は各リレーが自分で決めるため、ネットワーク共通の加入価格はない。NIP-11 自体に応答の見本として挙げられているリレー nostr.wine の例: «fees»: «admission»: ({«amount»: 18888000, «unit»: «msats»}) — これは文書内の例におけるリレーの記載であって、私たちの集計でも現在の価格の保証でもない

出典, 確認済み 2026-08-07

制限と上限

リレーは自らの制限を情報文書で公表する: max_message_length (受信 JSON のサイズ)、max_content_length (content フィールドの文字数)、max_event_tags、max_subscriptions、max_limit。認証やプルーフオブワークを求める場合もある

NIP-11 の文書。プロトコル自体に長さやサイズの制限はない

出典, 確認済み 2026-07-28

リレー relay.damus.io は確認日の時点で、メッセージの上限 1 000 000 バイト、同時購読 200 件、取得上限 500 イベントを公表している。プログラムは strfry

この数値はこのリレーのものであり、別のリレーでは異なる

出典, 確認済み 2026-07-28

リレー nos.lol は、メッセージの上限 131 072 バイト、購読 20 件、取得上限 500 イベントを公表している

リレー情報文書のリクエストで測定した

出典, 確認済み 2026-07-28

リレー relay.nostr.com は、メッセージの上限 131 072 バイト、購読 200 件、取得上限 500 イベントを公表している。表明している NIP は 1、2、4、9、11、28、40、45、70、77

damus.io と nos.lol も同じ NIP の組み合わせを表明している

出典, 確認済み 2026-07-28

制限

共通のルールはない: 何を受け入れ何を保存するかはリレーの所有者が決める。プロトコルは、リレーの情報に利用規約へのリンクを置くことを想定しているにとどまる

削除は«削除の要求»として記述されており、実行は保証されない

出典, 確認済み 2026-07-28

スパム対策: リレーは指定した難易度のプルーフオブワークまたは認証を求めることができる。一部のリレーは有料で、プロジェクトの説明によればそれがスパムを減らす

Nostr.watch はリレーのカタログとして、nostrapps.com はクライアントのカタログとして、プロジェクトが推奨している

出典, 確認済み 2026-07-28

nostr.com のロボット向けファイルは、すべてのエージェントにサイトの巡回を許可している

個別に確認済み

出典, 確認済み 2026-07-28

法的事項

NIP 一覧のリポジトリは、ライセンスを示さずに公開されている

プロトコルには、契約を結べる法人が存在しない

出典, 確認済み 2026-07-28

API アクセス

nostr.com のクライアントは既定で 6 つのリレーに接続する: relay.nostr.com、relay.damus.io、nos.lol、nostr.bitcoiner.social、nostr.mom、relay.snort.social

一覧はインターフェースにそのまま表示される

出典, 確認済み 2026-07-28

独立した«公式 API»はない: インターフェースはプロトコルそのものであり、どのプログラムでもリレーへ websocket を開ける。開発者キーもアプリの審査も存在しない

特定の機能に対応しているかは、リレーの情報文書で確認する必要がある

出典, 確認済み 2026-07-28

言語

トップページのインターフェース言語：en

言語はマークアップの属性から、言語版は hreflang から取得した

出典, 確認済み 2026-07-28

カタログの区分： 類似のすべて 関連項目： カタログ索引 · 予約投稿ツールの比較 · 状況別の選び方 · プラットフォームの制限