先日、ツイッターのポリシーに「競合他者へのリンクやプロフィールの共有禁止」という文言が追加され、批判を呼びました。(のちに撤回、ツイートは削除)

Specifically, we will remove accounts created solely for the purpose of promoting other social platforms and content that contains links or usernames for the following platforms: Facebook, Instagram, Mastodon, Truth Social, Tribel, Nostr and Post.
— Twitter Support (@TwitterSupport) December 18, 2022

名指しで指定されていたSNSには大手や、ツイッターから追放されたトランプ氏が設立して物議を醸したものと並んでNostrという名前がありました。つい先週までアクティブユーザーが高々数百人程度という小規模さにも関わらずリスト入りした理由はおそらくツイッターの現CEOであるElon Musk氏から警戒されているためだと考えられます。なぜなら、最近ツイッターの創業者で元CEOのJack Dorsey氏が興味を持ち、Nostrの主要開発者に14BTCの資金提供をしたり、１ユーザーとして助言しているためです。

このNostr、実はライトニングで大活躍しているfiatjaf氏が２年ほど前に開発した分散メッセージプロトコルなのです。LNURL/Lightning AddressやLntxbot、Etleneum (今年7月にサービス終了)などでおなじみの同氏に加えて、CLNプラグインのCommandoを使ってブラウザからライトニングノードに通信する実験をしていた@jb55氏がNostrの主要開発者です。

Lightning Addressと乱立するインボイス請求方法
ライトニングネットワークを用いたペイメントにはインボイスという１回１回の支払いごとに異なる情報が用いられます。そのため、非推奨ながらも固定のアドレスを使い回せるオンチェーンの送金と異なり、ライトニングで送金を受け取るにはインボイスの発行という手順が最初に必要になります。 送金を送金者から開始したい場合に、宛先のノードにインボイスの発行を依頼する方法は前からいくつかありましたが、最近このあたりを考えている人が多いように感じます。今日は8/20にリリースされたLightning Addressを紹介し、他の方法との類似点や違いを見ていった後に、将来的にどうなるのか予想してみます。 https:…
ビットコイン研究所加藤 規新
LN経由でウォレットを操作する？変わり種ウォレット：LNLink
iOSのTestFlight機能ででテスト公開中のアプリケーションに、William Casarin (@jb55)氏の“LNLinkというものがあります。「ライトニングネットワーク越しに」ライトニングノードを管理できるアプリという触れ込みが面白かったので、実際にコードを見てどうなっているのかを調べてみました。 LN上のデータのやり取り LN上で特定の相手にデータを送る方法は大別して２通りあります。１つ目は支払いにデータを付加する方法(TLVメッセージなど)、２つ目は相手に直接ピアとして接続してデータをやり取りする方法です。 支払いにデータを付加する方法の特徴としては匿名性が高いことが…
ビットコイン研究所加藤 規新

実はNostrの紹介記事を2021年1月に書こうと下書きまで用意していましたが、当時はまだ立ち上げ後間もなかったこと、単純な技術なので紹介する内容があまりなかったこと、そして将来性が不確かだったことを理由にボツにしました。結論から言うと後者２つの印象は今も変わりませんが、いま話題なので紹介します。

Nostrは分散SNSではない

まず１つ大事なことを説明します。Nostrは分散SNSではありません。

NostrとはNotes and Other Stuff Transmitted over Relaysの略語で、そのまま「Relayサーバーを介して手紙やその他いろいろを通信する」ことが目的のプロトコルです。上記のツイッターの競合としての指名を見るとNostrの主用途はSNSのように見えますが、プロトコル自体はJSONオブジェクトをやり取りする通信のプロトコルなので工夫すれば様々な用途に応用できます。

そう、分散SNSは単に一番最初に流行ったユースケースなのです。

ところが、もう１つ触れなければならない点があります。Nostrを「分散」と表現すること自体もあまり正確ではありません。P2Pの仕組みはなく、ユーザー同士の通信でも必ずサーバーを介するためです。

Nostrの仕組みはユーザー(Client)がいろいろなサーバー(Relay)に接続し、そのすべてにデータを投稿し、すべてからデータを受け取るというものです。多数のRelayが使えることで、もしその中の１つからBANされても他のものが使えるという形で検閲耐性を謳っています。Relay同士は通信しません。自分自身でRelayを動かすこともできますし、そこに投稿できる人、アクセスできる人を制限することもできます。

しかし、BANされたらフォロー・フォロワーも失われデータも失ってしまうという巨大な単一障害点を数カ所にバックアップできるようになったことは確かですが、あくまでクライアント・サーバーの関係に基づいており、一般的には第三者が運営するRelayに依存します。また、スケーラビリティ面でもRelayやユーザーの数だけ増える冗長な通信やデータ保管が課題となってくるでしょう。ただこのシンプルさがクライアントの開発を容易にし、昨今のブームにつながっているのは事実です。

ここから先はそんなNostrの特徴と欠点、それらから導き出される将来像について解説します。

Nostrの特徴と欠点

シンプル

前述の通り、Nostrは非常にシンプルな仕組みです。ユーザーは秘密鍵・公開鍵を生成して参加し、発信するすべてのメッセージに署名します。ユーザーはRelayに接続し、Websocket経由で流れてくるたくさんのメッセージの中から自分が興味のあるもの(発信者をフォローしているもの)を表示します。任意のユーザー、任意の投稿などを取得することもできます。

このシンプルさの代償として、Relayを流れるすべての通信が取得できてしまいます。もちろん、電子署名によって偽造対策されていたり、ユーザー間のDMなどは暗号化されているので第三者に内容はわかりませんが、それでもプライバシー面で好ましいとは言えません。また、通信量が膨大になってしまうという次の特徴にもつながります。

LNURL vs Bolt12においても明らかなようにfiatjafはシンプルさ重視の哲学があるようで、とても彼らしいプロダクトに感じます。

【2020/11/19】BOLT12の新しいインボイス形式がライトニングをよりEコマース向けに進化 (Facebook)

BOLT12の新しいインボイス形式がライトニングをよりEコマース向けに進化
エンドユーザーでもライトニングネットワークの利用時に必ず目にするインボイス。現行の形式のかゆいところに手が届く、新しいインボイスの仕様が提案されています。今日はライトニングの新しいインボイスの仕様として提案されているBOLT12について見ていきます。 BOLTとは Basis of Lightning Technology (BOLT)とは、ライトニングネットワークの仕様を定めた仕様集です。現時点ではBOLT0～5と7～11が定められています。(6番は7番に置き換えられて欠番です)現在のインボイスの形式を定めたBOLT11の欠点を改善するものとして、今回紹介するBOLT12が提案されていま…
ビットコイン研究所加藤 規新

通信・データ保管の冗長性のコストが高い

現在のNostrはテキストのみのJSONオブジェクトにのみ対応し、Relayに画像などを保存してもらうことはできません。それにも関わらず、ツイッターのような完全に中央集権的なサービスと比較して構造的に通信量やデータ保管が課題となります。Relayに接続しているユーザーの通信がすべてWebsocketで他のユーザーに転送されるからです。ただでさえテキストベースのSNSは儲からないとTwitterが証明している中で、Relayを運営するコストをどう回収するかが課題になります。

もちろん、Relay単位でライトニング払いで従量課金やサブスクリプションということも考えられますが、ユーザーにとって負担が大きすぎると結局ユーザーは単一のRelayのみを使うようになり、Twitterと同じ問題に直面するかもしれません。

また、収益化のためにRelayが提供する機能を差別化していくことも考えられます。現在のNostr Relayはほとんどがオープンソースなので需要のある機能はすぐにコピーされて実装間の差異が小さくなりがちですが、将来的には便利なRelayが数個ないし１つという状況になるかもしれません。これもまたユーザーが単一のRelayを使う動機になってしまったり、Relay同士の互換性がなくなってNostrの存在意義が形骸化することにつながりかねません。

もちろん自分がBANされるリスクが高いと感じているユーザーだけでもお金を払って複数のRelayを使えば問題ないという視点もあります。

秘密鍵を変更する方法がない

他にも欠点は色々考えられますが、３つ目に挙げたいのは秘密鍵を変更するスキームが存在しないことです。

現在Nostrのクライアントの大半はブラウザで動くウェブアプリで、直接秘密鍵を生成・入力させるUIになっています。その結果、一般的な脆弱性によって秘密鍵を盗まれたユーザーが既にいるようです。Nostrは秘密鍵自体をIDとして利用しているので、残念ながら秘密鍵を盗まれるとアカウントを不正利用されたり、暗号化した過去のDMを解読されてしまいます。これがDIDの文脈で単純に秘密鍵・公開鍵ペアをIDとして使わない重要な理由の１つですが、Nostrではシンプルさのために安全性が犠牲になっています。

将来的にはリカバリー用のキーペアを登録し、署名鍵とは別に管理できるようになるかもしれませんが、十分に後方互換性を持たせ、各Relayで同じタイミングでアップグレードできなければ混乱が起きる可能性があります。P2Pソフトではなくても複数のRelayを利用することが前提となる仕組みのために仕様変更には慎重さが求められ、このあたりはNostrの開発者たちの弱点という印象があります。

リリース後のアップグレードが難しいことはWeb5がソフトウェアのリリースや仕様策定にたっぷりと時間をかけている理由の１つでもあります。

恒久的に使う予定のアカウントの作成はリカバリー方法が用意され、セキュアなクライアントが充実してからでいいでしょう。

Nostrの将来像

さて、ここまでやや厳し目にNostrの特徴を説明してきました。コスト高と引き換えに冗長性を、複雑な機能を廃してシンプルさを手に入れた簡易な電子署名・暗号メッセージプロトコルとしてNostrはどのような用途に使われるようになるのでしょうか。

人間にとってのユースケースから考えると、やり取りのたびにアカウントを生成して使い捨てる、一時的な匿名コミュニケーションを手軽に実現できることが長所に思えます。メッセージの暗号化まで可能なので、事業者のヘルプセンター、Coinjoinなどマルチパーティートランザクションの生成などに活用できそうです。内容次第でRelayの運営者がリーガルリスクを負う可能性はありますが、Nostr Relayを立ち上げるだけで簡単に実装できるまともなユースケースもたくさんあります。

では機械にとってのユースケースを考えると、Nostrは「Relayがデータの保存と配信を行ってくれるDBaaS」と捉えることができます。つまり、冗長性を持たせて保管したいデータや公共性の高いデータを様々なRelayに託し、エンドユーザーへの配信も任せてしまえます。このようにテキストデータをRelayに保存させることで自前のバックエンドを持つ必要から解放されます。これは小規模アプリの開発者からすると非常にありがたいことです。(イーサリアムのDappsがInfuraやAlchemyに頼っているのと同じような構図)

もちろんコストの問題があるので、有料化の流れは避けられないかもしれませんが、自前のRelayを用意することもできるのでRelay提供者のサービス内容への依存性が低いメリットがあります。不特定多数に利用させなければ通信量の問題もある程度軽減されます。

さっそく自分も「Blockstream Satellite経由で宇宙から受信したテキストや画像データを掲載する掲示板」blocksat.infoをNostr対応させてサーバーとDBのホスティング料金を節約してみようと思います(笑) また、おすすめのクライアントソフトがあったら教えてください。

私のNostrアカウント：
d2b6b012485ec6dbfc7d844446d2608120d25dc54e432555582c78ce9bb65dc4