1 ポイント 投稿者 GN⁺ 2025-09-21 | 1件のコメント | WhatsAppで共有
  • Nostr は中央統制を排したオープンな コミュニケーションプロトコル であり、多様なクライアントとリレーの組み合わせを通じて情報を自由に流通させるよう設計されたアーキテクチャ
  • ユーザーは個人の 鍵・署名 に基づいて身元とメッセージの真正性を確保し、クライアントは複数のリレーに同時接続して分散的な配信と参照を行う
  • プロトコル自体に所有者はいないが、各 リレー運営者 は独自の方針に従って検閲・遮断の基準を設定し、利用者はどのリレーを読むかを選べる
  • Twitter型マイクロブログを超えて、クローズドグループ(NIP-29)マーケットプレイス分散Wikiコード協業/トレント/ライブストリーミング などへとサブプロトコルとエコシステムを拡張中
  • まだ完成された製品というよりは、開発者・アーリーアダプターの参加 が必要な段階であり、スパム・スケーリング・発見性といった課題を クライアントとリレーの組み合わせ戦略 で解決している途中

An open protocol with a chance of working

  • Nostr は政治的傾向に依存しない コミュニケーションの共有地 を志向し、誰でも実装・利用できる シンプルな標準 として拡張性のあるクライアント/サーバーアーキテクチャを定義している
  • 特定の企業や政府に支配されず、多様なクライアント が同じ情報レイヤーをそれぞれ異なる視点で見せるという、オープンで混沌としたインターネット初期の感覚 を受け入れている
  • サイトでは実際のクライアントのスクリーンショットを示し、エコシステムの 多様性 と実利用志向を強調している

Many clients, many servers

  • 集中型サービスとは異なり、Nostr の クライアントは複数のリレー に同時接続する
    • 各リレーは WebSocket ベースのサーバーで、関心のあるイベントを問い合わせて購読する 分散型投稿ストレージ の役割を果たす
    • 特定のリレーだけを単一の信頼源にしないため、検閲・シャドウバンのリスク分散 効果がある
  • 参考資料リンクを通じて従来モデルとの違いを 学習資料 として案内している

A new paradigm for communication

  • ユーザーの身元は秘密番号である プライベートキー で表現され、すべてのメッセージは デジタル署名 を含むため、権威機関がなくても 投稿者の真正性 を検証できる
  • この 暗号学的信頼基盤 が検閲耐性のある ブロードキャスティング を可能にする
  • 人にわかりやすい説明動画へのリンクを提供し、入門のハードルを下げている

The protocol is ownerless, relays are not

  • プロトコルは 無主 だが、リレーは 私的所有 であり、各運営者が任意の 受け入れ・拒否基準 を設定できる
  • 利用者は読むリレーを自由に選べるため、表現の多様性接続先の選択権 が共存する
  • 「検閲賛成/反対」という二分法ではなく、サーバーごとの規則の多元性利用者の選択 を中核に置いている

Freedom of association

  • ネットワーク効果が単一組織に縛られないため、特定の利用者グループが他者を 構造的に害しにくい構造 になっている
  • 関連動画を通じて 結社・分離の自由 を強調している

Your own piece of Nostr

  • プログラマーは簡単に 独自リレー を動かして 独自ルール を適用できる
  • リレー実装リポジトリへ案内し、貢献と実験 を促している

New Ideas — Exploring the commons

  • Twitter型 マイクロブログ を超えて、動画/長文/画像/ボイスノート など多様なデータ型を扱える
  • クローズドグループ分散WikipediaカウチサーフィンマーケットプレイスWebアノテーション といったサブプロトコルの実験が活発に進んでいる
  • git ベースの分散コード協業ファイルホスティングトレント共有動画ライブ配信 などで Nostr を 発見・調整レイヤー として使う試みが進行中
  • 標準提案集である NIP を通じて機能拡張と相互運用性を図っている

Ecosystem — Still under construction

  • オープンソースソフトウェアと大きなユーザー基盤はあるが、まだ 洗練された完成品 の段階ではない
  • 初期ユーザー・開発者 の参加が、プロトコルの流れと UX改善 に重要である

Microblogging — The outbox model

  • アウトボックスモデル は検閲耐性のあるクライアント実装の定石として紹介されているが、パラメータは流動的 である
  • 実装ガイドでは、リレーを ストレージのように扱う方法購読/配信戦略 を説明している

Relay-based groups — NIP-29

  • NIP-29 はフォーラム/チャット型の クローズドグループ をリレー基盤で効率的に実装する方法を示している
  • 単一リレーへの依存を減らしながら、検閲耐性 を保つ構造を案内している

How Nostr works

  • 過酷な環境でも ユーザーとオーディエンスの接続 を維持する 真の自由 の提供を目指している
  • 複数リレー、ローカルインデックス、選択的読み取りなどによって 継続的なアクセス性 を担保する

FAQ — 主要な質問と回答

  • 「プロトコル」とは何か

    • 複数のソフトウェアが相互通信するための 共通言語 であり、e-mail/HTML/HTTP のように特定アプリに依存しない 相互運用性 を意味する
    • ひとつの言語を共有する 複数のアプリ は相互に代替可能で、それぞれ 表現・UI を変えられる
  • スパムや望まないコンテンツはどう扱うのか

    • 基本フィードは 自分がフォローした人 の情報だけを取得するため、プッシュ型スパム は起こしにくい
    • コメント閲覧のようなオープンな参照はスパムにさらされうるため、2ホップ隣接制限信頼リレーのホワイトリスト有料/認証リレー などの 接触面縮小戦略 を活用する
    • 完璧な解決策はないが、Nostr は レジリエンス を前提に設計されている
  • 大規模採用時のスケールは可能か

    • 基本は クライアント/サーバーアーキテクチャ であり、ユーザーが数百のリレーへ 自然に分散 するため、負荷分散 が内在している
    • 多数のリレー接続が懸念されるかもしれないが、人々は 類似の関心を持つアカウント群 をフォローするため、リレーが自然な共通分母を形成する
    • ネイティブアプリは数百の WebSocket を処理可能であり、ローカルデータベース へのバッチ要求によって性能を確保する
  • オンラインハラスメントにはどう対応するのか

    • スパムと同様に望まない投稿はありうるため、ブロック共有ブロックリスト読み取りを制限したリレー などで 露出の最小化 を実現する
    • 友人限定表示 などの保護機能は リレーのポリシー でエミュレートできる
  • なぜ Mastodon/フェディバースではないのか

    • 暗号技術の欠如 により マルチマスター が不可能で、サーバー所有の身元 の問題や サーバー間の信頼移転 の問題が生じる
    • サーバー運営者への 過度な信頼 が必要であり、ドメインや DNS への依存も問題として指摘される
    • Nostr は サーバー非依存の身元リレー選択 によって、本当のコミュニティ をリレー単位で形成できる
  • なぜ Bluesky/ATProto ではないのか

    • PLC ベースの身元の中央集権化 と Relay-AppView-Client の単一正本フローにより、検閲・再配置・シャドウバン のリスクが大きい
    • マルチソース化で改善できる可能性はあるが、そうなると実質的に Nostr に近い構造 に収束する
  • リレー運営のインセンティブは整合しているのか

    • サーバー運用コストは低く、コミュニティ/個人/組織/ホスティング事業者 など多様な主体が安価にリレーを提供できる
    • ユーザーはどこへでも移れるため、多様な経済主体 の動機が整合する
  • 複数のリレーに散らばったコンテンツをすべて見られるのか

    • 世の中のすべてを見られないのと同じく、焦点とアクセス許可 の範囲内でしか観測できない
    • これは 注意の集中リレー選択 に伴う自然な制約である
  • 検索はどう動作するのか

    • 本質的には 見たものでなければ検索できない ため、公開検索を望むなら クローラー/インデクサー が選択的にネットワークを収集する必要がある
    • クライアントは ローカル保存 により、自分が見た/やり取りしたコンテンツを ローカル検索 で素早く見つけられる
    • トピックリレー は独自インデックスによって 有用な範囲検索 を提供できる
  • アルゴリズムがなければ新しいコンテンツはどう見つけるのか

    • フォロー関係の 相互作用グラフ探索 が基本であり、Nostr でも ローカル/リレー/AIベースのアルゴリズム を持てる
    • クライアントローカルでの ハイライト/再浮上表示、リレー側の キュレーション など、多様な 発見性メカニズム を適用できる
  • ビットコインとの関係は何か

    • 暗号学の原理 を共有し、ビットコインコミュニティから始まったが 依存関係はない
    • Zaps は一部クライアントが実装した ビットコイン投げ銭標準 であり、完全に任意 である

1件のコメント

 
GN⁺ 2025-09-21
Hacker News の意見
  • Nostrの暗号技術が深刻なレベルで脆弱だということは知っておく必要がある
    この論文で示された主な脆弱性は次のとおり

    • イベントプロトコルが公開鍵認証を行っておらず、対称鍵署名は形式的なものに過ぎない

    • Damus、Irisのような主要クライアント2つは、署名そのものを検証していない

    • システム内のDMは認証のないCBC暗号方式なので、攻撃者がメッセージのビットフリップで内容を改ざんできる

    • アプリが自動リンクプレビューを行うことで、昔のEFAIL攻撃が再現可能な状態になっている

    • システムに鍵の区別がなく、ユーザーをだましてセッション鍵を誤用させることができる

    • 全体として2000年代半ばレベルの初歩的なミスである

    • Nostrにほかの利点があるかもしれないが、エンドツーエンドの安全性を求めるなら適したプラットフォームではない

    • Nostrコミュニティで長く活動しており、Safari向け拡張機能も作ったことがある
      その論文は読んでいないが、指摘されている点にはNostrプロトコル自体への誤解や思い違いがあると思う
      Nostrでは公開鍵そのものがアイデンティティとして機能する
      暗号学的には公開鍵ベースの身元は偽造不可能である(ただし実装バグは別問題)
      UXの面では「公開鍵の所有者の本当の身元確認」が難しいが、これは暗号の安全性とは別の問題だ

    • 「イベントプロトコルが公開鍵認証をしない」というのはまったく意味が通らない
      ほとんどのクライアントとリレーは実際に署名チェックをしている
      Damusの作者として言うと、それは古いバージョンの話だ — その問題は解決済み
      初期には信頼できるリレーにだけ接続しており、それらのリレーが署名を検証していた
      最適化された署名検証のためにnostrdbという組み込みDBまで作った
      DMが認証なしのCBCなので攻撃可能だという指摘も誤りだ
      ノート全体がsecp256k1署名でカバーされている
      自動リンクプレビューや画像などはオンオフ可能で、心配ならVPNを勧める

    • Nostrでどの鍵アルゴリズムが使われているのか探そうとしたが、文書のどこにも直接は明記されていない
      検索するとどれもBlech32(ビットコインの鍵エンコーディング)関連の話に行き着く
      hellonostr.dev の紹介文書を見ると、エンコーディング自体にバージョン情報が含まれていることが分かる
      npub1abcxyz... 形式では npub がヘッダー、1 がバージョン、その後ろが鍵に当たる
      関連文書を参照してほしい

    • 指摘された問題は、実際には実装依存のもの(署名しないアプリ、これはプロトコルの本質を壊す行為)か、
      初期の暫定的な暗号化方式に由来するものだ(すでにNIP44などへ置き換えられ、独立監査も受けている)
      現時点では致命的、あるいは実際に対応が必要な問題はない

    • なぜこうした問題を今まで一度も聞かなかったのか分からない
      早急に議論されるべきだ
      プロトコルの観点でより安全な連合型プラットフォームはbluesky(at protocol)なのか、fediverseなのか気になる

  • 多くの人がNostrリレーが連合してメッセージを共有していると誤解している
    実際にはそうではない
    Twitterクローンを作るなら、クライアントアプリが複数のリレーを直接検索・投稿しなければならず、
    共通のリレーを使っていなければ互いのメッセージを見ることができない
    単一リレーだけを使えば完全に中央集権化してしまい、
    複数リレーを使うと遅くて面倒で、ユーザーはどのリレーに接続するか自分で把握しなければならない
    NIP文書も雑然としていて保守が大変だった

    • リレー同士も連合できる
      Nostrプロトコルは連合するかどうかについて何も規定していない
      私はインデクサー(リレー)を運用していて、このインデクサーはほかのリレーと連携している
      ActivityPubリレーのように、どのクライアントでもインデクサーに接続してブートストラップやイベントメタデータ検索ができる
      同じリレーに接続していなくても、クライアント同士はさまざまな方法で情報をやり取りできる

    • とても興味深い難題だと思う
      NIP65のようにプロフィールメタデータに読み書き用リレーを明記すれば、
      クライアントは適切なコンテンツを簡単に見つけられる
      そのほかにもいろいろなアイデアが試されている
      解決可能な問題だと思う

    • リレーはユーザー生成コンテンツを所有しないので、連合の必要はない
      クライアントは通常、ユーザーが自分で選んだリレー群に依存する
      それでも主要リレーのかなりの数が、ほかのリレーのイベントも保存する形(一種の連合)で運用されている
      例: Primal, TheForrest, nostr.land
      nostr.landはスパムフィルタリングと複数のパブリックリレーのノート集約を主目的とする有料リレーだ
      望まなければ別のリレーを選べる
      ほとんどのユーザーは現在のリレー連合で99%以上のノートを見られるが、実際の数値は検証できない
      一部のクライアントと署名者はノートを非公開で保存しており、
      もしリレーがノートを検閲しても、別のリレーへいつでも再投稿する形で対処できる
      実際、人気の有料リレーを使うと、4回中3回の書き込みイベントで「すでに別のリレーに登録済み」という警告をすぐに目にするようになる
      最後に、リレーは自らクライアントの役割も果たし、この機能のおかげでモバイル環境や低速ネットワーク時のキャッシュとして便利だ
      アウトボックス方式には問題点もあるが、クライアント開発者が選択肢として提供できるので、
      連合型からP2Pまで柔軟に拡張できる

    • ほとんどのクライアントがアウトボックスをサポートしているので、同じリレーを使う必要はない
      各ユーザーは別々のインボックス、アウトボックスリレーを持てる

    • NIP文書に変な部分があったのは事実だが
      ほとんどのNIPは着実に改善されており、
      公式の定期リリースがあれば細かい問題として解決するはずだ
      多くの開発者が素早く対応している

  • こういうプロジェクトは、ユースケース、思想、実装を明確に分けて説明してくれるといい
    初見では、これがソーシャルネットワークなのか、プロトコルなのか区別がつかない
    「検閲志向なのか? ブログ記事を読まないといけないのか?」
    Scuttlebutt、Mastodon、ActivityPub、Diasporaなどもまったく同じだ
    そもそも「メールと何が違うのか」「Twitterと比べて何が良いのか」
    理解する前に「これは技術実装なのか、製品なのか、サイトなのか、アプリなのか」から混乱する
    Urbitも正確に説明できる人はあまりいないだろう
    それでも「Web3」よりはましだと思う
    BlueskyやGeminiあたりはその点が明確だ

    • NostrはP2P構造とWebアーキテクチャのあいだで折衷したソリューションだ
      Webサーバーを活用してインターネットの流れに合わせつつ、
      ユーザーはサーバー依存を下げ、公開鍵と署名によって身元とデータ認証を強化する
      その結果、ユーザーには「credible exit」のような権限移譲が生まれる
      だから新しいユースケースというより「新しいインターネット」と呼んでいる
      プラットフォーム中心ではなくユーザー中心のトレードオフがあり(UXパターンの違いも含む)、
      既存ソーシャルネットワークの検閲耐性に近い価値を提供するので、
      社会的な応用例が多く見えるのだろう

    • 実際にそういうサイトを作ってみるといい

  • 製品説明の最初の一行に “apolitical” という言葉を使っているのがすごく変だ
    同時に “open” という言葉も入っているが、ここでは本質的に政治的な意味を持つ
    Nostrに暗号通貨との関連があったか覚えていないが、何か混乱した記憶がある

    • Nostrには「nostrコイン」もなく、オンチェーンアクションもない
      その点はとても気に入っている
      特にNostrと暗号通貨コミュニティの交差が完全に重なって見えたからだ

    • ビットコインを主に使う利用者が多い

    • 右翼が自分たちを “apolitical” と呼んできた歴史は長い

  • Nostr、Mastodon、Discordのような連合型・分散型サービスは、
    クライアントアプリ自体に自前のリレーを内蔵して、すべてのユーザーがサーバーの役割も果たすようにしないと、本当の分散型SNSは実現できない
    古典的なP2Pソフトウェアはすでにそうしてきたし、実際にうまく動いている
    ただし、ユーザーが自分で取得していないデータまで任意にホスティングすると、
    違法コンテンツによって処罰される問題(例: 空港で違法薬物の所持が発覚するケース)に似たことが起きる
    こうしたリスクのため、次世代のP2P構造にはAIベースの「違法コンテンツフィルタリング(例: CP、映画)」が必要だ
    あるいは完全に閉じたコミュニティとして作り、
    もし問題が起きてもコミュニティ内部だけで責任を負うようにすべきだ
    結局、すべてのクライアントがサーバーにもなるモデルが最良の分散型ソーシャルモデルだ

    • irohというプロジェクトがこのように動作する
      「リレー」は2つのクライアント間の接続を中継する役割を果たすだけだ
      iroh の概念説明 を参照

    • かっこいいが、実際のP2P構造はうまく回らない
      irohですら内部的にはリレーに依存している
      Nostrはリレーにポリシー執行権限を直接与えている(別途ハックなしでそのように実装されている)

  • NostrがHNトップに来てうれしい
    まだ初期段階だが、Nostrでは “zapps” (Bitcoin-Lightningベースの即時少額決済)も可能だ
    広告やアルゴリズムの問題なしにクリエイターへ直接少額報酬を送れる、
    分散型で広告のないSNSモデルだ

    • NostrクライアントのPR作業にもzapsで報酬を出せる
      関連するバウンティの例を参照

    • Bitcoinはすでに規制が厳しい

    • こういうコメントを読むと登録したくなるが、実際の探索ページでは
      人々が本物の商品(旗、カカオ、代替教育など)を売買していて印象的だった
      単なる「日記を公開してお金をくれ」ではない点が新鮮だった
      実際の商品やサービス、クリエイターのためのプラットフォームだ

    • Nostrは少なくとも5年前から存在している
      パンデミックの時期にもTwitterからNostrへ移る人は多かった
      いまさら初期段階という表現には同意しにくい

  • さまざまなNostrアプリの紹介
    openux.app - Mobbin代替サービス
    kinostr.com - リアルタイム映画チャット
    zap.stream - Twitch風ライブストリーミング
    dtan.xyz - トレント
    zapstore.dev - 許可不要のアプリストア
    nostrnests.com - オーディオルームチャット
    zapmeacoffee.com - Buy Me A Coffeeに類似

    • NostrベースのQuora/StackOverflow代替サービスも開発中だ
      asknostr.site
      このように分散ソーシャルプロトコルは多様なユースケースを可能にしており、
      ユーザー側の利点は
      • VC企業に「データを奪われる」ことを防げる
      • 貢献時に報酬(zaps/お金)を受け取れる
      • データには誰でも自由にアクセスできる(署名できるのは著者だけ)
  • Nostrはマイクロブログサービスとして使うだけでなく、下位レイヤーとしてさまざまな用途がある
    例: Trystero
    中央サーバーなしでP2P WebRTC接続を確立する際にNostrを使っている
    (MITライセンス)

    • 私もNostr、Bittorrent DHT、Mastodonなどを使った検閲耐性のあるマルチチャネルブロードキャストを考えたことがある
      すべての手段が失敗したときにだけネットワーク断絶が起きるようにするのが目標だ

    • これに似た形で、NostrやATProtoが
      P2Pインスタントメッセンジャーの「オフラインメッセージ保存場所」としても使えるのか気になっていた
      接続確立用途に使うのも斬新な方法だ

    • 本当にすばらしいアイデアだ
      私も似たようなことをやってみたかったが、すでに誰かが作ってくれていて時間が節約できた

  • こうした技術系ソーシャルネットワークが、なぜ従来のWebのように
    それぞれの個人ホームページ(オリジナルWebのような形)を連携する構造ではなく、
    別個のアカウントベースのプラットフォームへ向かうのか理解できない
    RSS以外で、個人サイト運営を促しつつ、
    中央化されたソーシャルメディア(チャット、フィードなど)を付け加えたネットワークの試みはなかったのだろうか

    • ここでいう「アカウント」とは、実質的には公開鍵/秘密鍵のペアのことだ
      自分のリレーも直接運用できるし、
      同じ公開鍵でどのリレーでも使える
      投稿も望むすべてのリレーへブロードキャストできる
      望むなら投稿ごとに新しい鍵を生成することも可能だ
      Mastodonなどはアカウントがサーバーにひも付くので移動性と自由度が低い
      ただし、アカウント復旧の方法がまったくないので、それは問題になり得る

    • RSDS(Really Simple Decentralized Syndication) を見るとよいかもしれない

    • 大まかにはnostrがそういう構造だ
      ただしWebサイトの代わりに「ノート」というデータ型を使い、サーバーの代わりに「リレー」だけを使う

    • なぜ「明確に技術者向けサービス」だと思うのかと質問したい
      創業者の頭の中を決めつけているのではないかと反論したい

    • 本質的には、すでに複数の技術を組み合わせて
      個人ホームページ/チャット/フィードシステムを自分で作ることはできる
      ただ、こうした混合モデルの現実的な問題は

      • 参入障壁: 非技術者向けの使いやすさ向上
      • 発見性: 情報探索や相互接続の問題
      • 持続可能性: 運用コストの分担
      • ガバナンス: コミュニティ内の自治機能
        これらすべてを同時に解こうとすると、どうしても折衷が生じる
        完全な分散化は発見性やアクセス性の問題との引き換えになる
        「もはやアカウントは不要だ」という主張も、オンライン・オフライン双方での複数身分の問題と絡む
        結局これは価値選択の問題であり、技術者に人気のある多様な実験的分散サービス(例: Mastodon、Nostr、Smolweb)は、
        初期インターネットのマインドセット(カウンターカルチャー、オープン、標準化、組み合わせ可能性)の影響を受けている
        すべての人が満足する案はあり得ないのだから、
        インターネット本来の価値は多様性、標準化、オープン性にあると思う
  • “apolitical communication commons”
    一部の人は、「非政治的」というラベル自体が
    すでに政治的な発言であり、権力的な立場だと指摘する

    • 「政治」への恐れがなぜそんなに大きいのか疑問だ
      市民として政治参加は当然の義務だという古代ギリシャの基本原則を例に挙げる
      実際、idiot という単語の語源はapoliticalな人だ

    • “apolitical” という概念は、
      実際には権威主義体制の下では沈黙し、現体制を暗黙に支える者として認識される
      ロシアのような独裁体制では、これがそのまま自由の抑圧と弾圧への近道になる
      Nostrのようなサービスは、政府が「リレー運営は違法/犯罪」と宣言するような形で妨げられてきた

    • 「すべてが政治なら、政治は何でもなくなる」
      著者は単に非技術的な論争を避けたいだけにも見える

    • “apolitical” は、誰でも歓迎するという意味に解釈することもできる
      参入障壁はインターネット接続だけで、
      ここ10年のSNS検閲傾向への反動という文脈で使ったのだろう

    • ある人たちは、「特定の立場の特権を使って他人を助けるべきだ」とも主張する
      それはここにも当てはまるかもしれない