はじめに
Twitterはかつてないほどの嵐に包まれています。イーロン・マスク氏が経営権を握ってからのTwitter社が、他のSNSへのリンクツイートを禁止したり（昨年12月）、便利で自由な機能によってTwitterのシェアを支えてきたサードパーティのアプリを排除する（今年1月）だけではなく、恣意的な基準で多くのアカウントの凍結を繰り返すなど（今年2月）、中央集権型SNSが迎えうる最悪の結末を辿りつつあるのは、みなさんもご存じでしょう。
そのような苦境の中で、中央集権型SNSから脱するための取り組みが再び注目を集めています。Twitter社がリンクのシェアを禁止していた他のSNSには、MastodonやNostrといった非中央集権型のSNSも含まれており、強力な中央集権型SNSの運営主体でさえ脅威に感じるほどの勢いと力を持っていることを暗に示しました。
この記事では、非中央集権型のSNSが持つメリット・デメリットを振り返りながら、Mastodonなどの実装でよく知られるActivityPubとは異なるアプローチを採ったNostrというリレー型分散SNSについて掘り下げていきます。
Nostrとは何か？
Nostrとは、非中央集権的なSNSを構築するためのプロトコルのひとつです。より具体的には、Notes and Other Stuff Transmitted by Relays（リレーで送信されるメモなど）という名前の通り、必ずしも信頼できない複数のリレーを通じてクライアントの署名付きメッセージをやり取りするための仕組みと言えます。
リレーを通じてメッセージを送るとは、実際には何を意味しているのでしょうか？ これによって何を実現できるのでしょうか？ その詳細については、NostrのREADMEで他のSNS実装との比較を交えて示されています。
まずは上記資料の要点を元に、Nostrを含めた各種SNSの実装方法のメリット・デメリットについてまとめます。
従来のSNSのメリット・デメリット
中央集権型SNS
Twitterをはじめとする単一の運営主体がサービス全体を掌握する中央集権型SNSの問題点は、改めてここで論じる必要はないでしょう。恣意的なルール運用によるアカウントの凍結や投稿の削除を繰り返したり、投稿を勝手に選別して並べ替えたり、退屈で不快な広告を挟み込んだり……挙げればキリがありません。
もちろん、投稿を編集・削除したり、閲覧数などの統計情報を取得するような、非中央集権的なサービスでは難しい・面倒あるいは不確実な操作がシンプルに実現できるというメリットがあると主張することもできます。また、犯罪を誘発しかねない投稿や不快な投稿を未然に 防いでくれる のをメリットと考える人もいるでしょう。それでも、現実にTwitterが多くの人に不自由を強いて圧政を敷いている現実を見れば、権力集中によるデメリットの方が大きいと言わざるを得ません。
クライアント・サーバーモデルの連合型（decentralized）SNS
このような中央集権型SNSと比較すれば、Mastodonなどの主にActivityPubを実装した連合型SNSは自由なシステムです。インスタンスの管理主体が単一でないのはもちろん、お互いのインスタンスがどんな実装かも気にしません。このような連合型SNSに参加したいユーザーは、有志がまとめたインスタンスの一覧から1つ選んだり、自分自身でインスタンスを立ち上げて投稿を開始できます。
連合型SNSの最大のメリットは、あるインスタンスでBANされたとしても、すぐに別のインスタンスから再び参加できるという点でしょう。つまり、単一の運営主体によって特定のユーザーをネットワークから排除できないように、プロトコルの設計レベルで考慮されています。
そして、連合型SNSの最大のデメリットも、まさに今自分が参加しているインスタンスからBANされる可能性があるという点です。ActivityPubなどの連合型SNSプロトコルは、ネットワーク全体における参加の自由を保証するものであり、各インスタンス内で管理主体の意向によらず参加し続けられることを保証するものではありません。インスタンスの管理主体は独自の（時には恣意的な）ルールでアカウントをBANしたり、不適切な投稿を繰り返す他のインスタンスからの配信を丸ごとブロックできます。
連合型SNSにおいては「あるインスタンスでBANされたとしても、すぐに別のインスタンスから再び参加できる」ため、この欠点はあまり強調されません。しかし、実際にアカウントをBANされるといくつか致命的かつ不可逆的な被害を受けることになります。
まず、SNS上のIDはインスタンスを提供するドメインと結びついており、別のインスタンスに移ると同じIDを使えません。インスタンスがIDの信頼性を保証している、とも言い換えられます。連合型SNSに馴染みがなければ、GoogleアカウントがBANされてから同じ名前でYahoo! JAPAN IDを取得したらメールアドレスはどうなるか？と想像してみてください。ダイレクトメッセージなどのチャネルで主なやり取りを行っていれば、BANによるIDの不連続は大きな損害になりえます。
また、フォローや被フォローの関係を完全に移行することもできません。自分が再度リクエストすればよいフォローはまだしも、被フォローを自動で移行するには信頼性を検証する追加の機構が必要不可欠ですし、各インスタンスがそのリクエストを尊重するとは限りません。メールアドレスで例えるなら、相手の連絡帳を勝手に書き換えようとしているようなものです。
このように、SNS上のIDや他のユーザーとの関係をインスタンス間で維持できないという事実は、連合型SNSという概念が、実際には小さな中央集権型SNSを接続する仕組みに過ぎないことを示しています。これは個々人のアカウントがBANされるかどうかといった個別の損害を超えて、連合型SNSがごく少数の大きな中央集権型サービスの連合に陥る可能性さえも示唆するものです。多くのユーザーがひとつの場所に集まった方が利便性が高いという致命的な中央集権性を内包するプロトコルは、最終的には大きな中央集権型サービスの内部仕様に姿を変えてしまうでしょう。
インスタンスの登録窓口を公開せず、運営者ひとりで使い続けるスタイル（いわゆる「おひとりさまインスタンス」）はこのような連合型SNSの中央集権化を抑えうる有効な取り組みです。しかし、おひとりさまインスタンスであっても、ドメインの登録が強制的に廃止されたり、DNSブロッキングなどの措置で実質的にインターネットから排除される危険性が残っています。ドメインと一体になったIDの寿命は、そのドメインやドメインが運用するサービスのそれより長くなることはないのです。
P2Pベースの分散型（distributed）SNS
ScuttlebuttなどのP2Pネットワーク上で実現されるSNSは、ユーザーの通信を媒介するサーバーを持たないという点で連合型SNSと大きく異なります。これにより、連合型SNSが直面していた多くの課題を解決できるようになりました。ユーザーと運営主体のような権力の濃淡が存在しないため、特定のインスタンスからBANされたり、IDの寿命がドメインやインスタンスの状態によって意図せず短くなることはありません。
P2Pネットワークは不当な検閲に対抗できる非常に強力な手法であり、全ての問題を完全に解決できるように見えます。しかし、実際にこれらのシステムを使い始めると、別の問題に気付くことになるでしょう。例えば、お互いを発見するためのプロトコルが複雑で、時には上手く動作しなかったり、相手からのメッセージを受け取るために接続を維持する必要があったり、モバイル端末で使うには大きすぎる初期データを持ち続けなければならない場合があります。
このような実用上の問題を解決するために、多くのサービスではしばしば純粋なP2Pネットワークから離れて、アカウントとIPアドレスのマッピングを保持するサーバーや、モバイル端末から利用するためのゲートウェイを導入することになります。これにより高速で便利なサービスを実現できますが、もはや純粋なP2Pネットワークが掲げていた理想的な姿ではありません。
Nostrが実現すること
ここまで述べてきたSNSのデメリットを、Nostrではリレーとクライアントを用いたネットワークで解決します。リレーというのはNostrにおける役割を重視した名称であり、ネットワークの構造は連合型SNSと同じクライアント・サーバーモデルとみなせます。しかし、リレーは連合型SNSにおけるインスタンスとは大きく異なる存在であり、これこそがNostrの単純さと強い検閲耐性を実現しているのです。
連合型SNSにおけるインスタンスとは、ユーザーの権利や信頼性を一手に担う中央集権的な存在でした。一方で、Nostrにおけるリレーとは、接続されたクライアントの投稿を横流しにするだけのシンプルなサーバーです。連合型SNSにおけるインスタンスのようにドメインを通じてIDの信頼性を保証することはできませんし、別のリレーからメッセージを受け取ったり、別のリレーにメッセージを送ったりする仕組みはありません。また、ユーザーの同意もなく違法なコンテンツを削除するような権限を持つべきではなく、そうしたリレーは遅かれ早かれ利用されなくなります。
Nostrでは、各ユーザーはそれぞれが持つ秘密鍵で識別できるため、リレーが提供されているドメインにIDの信頼性を依拠する必要がありません。同様に各ユーザーの投稿は秘密鍵で署名され、その投稿を受け取った別のユーザー（のクライアント）が責任を持って検証します。これにより、あるリレーからBANされてもIDを失うことはなく、別のリレーに移動してもIDは変わりません。もちろん、被フォローの関係も影響を受けずに済みます。
さらに、リレーが受け取ったコンテンツに対して責任を負わないという点は、ユーザーが常に複数のリレーに重複して投稿できるという大きなメリットに繋がります。これにより、特定のリレーからBANされた際のダメージを最小限に抑えられます。これは、各インスタンスが十分な責任を負う連合型SNSではサポートされていない仕組みであり、ユーザーが独自にマルチポストを行うといった不明瞭な取り組みでしか実現できなかったものです。
クライアント・サーバーモデルのSNSについて、以下に改めてまとめてみます。
| SNSの実装 | サーバーへの信頼が必要？ | サーバーが複数存在できる？ |
|---|---|---|
| 中央集権型SNS | はい | いいえ |
| 連合型SNS | はい | はい |
| Nostr | いいえ | はい |
中央集権型SNSや連合型SNSは、常に利用しているサーバーを信頼する必要があり、連合型SNSは信頼するサーバーを自由に選べるようなプロトコルの導入で自由なシステムを実現できるようにしました。しかし、連合型SNSにおけるインスタンスの実態は小さな中央集権型サーバーであり、参加者をBANすることでIDやフォロー・被フォローの関係を喪失できる権力を持ち続けています。
これに対し、Nostrではリレーと呼ばれるシンプルなサーバーを置いて権力を集積できないようにしました。リレーが持つ責任や権力はごく小さなもので、ユーザーはいつでも複数のリレーを利用してシームレスに移行したり検閲に備えられます。自分自身でリレーを用意することもでき、見た目のよいドメインを持ち続ける必要もありません。
分散型SNSはサーバーへの信頼どころかサーバーそのものが不要になる理想的な仕組みですが、お互いを見つけるためのプロトコルが複雑になりがちだったり、必要な速度が出なかったり、新たに参加するコストが大きいといった実用上の問題に全てが押し出されています。これらの問題の多くはクライアント・サーバーモデルの採用で解決できるものであり、サーバーの責任を各ユーザーに再分配したNostrはバランスの取れた解決策と言えるでしょう。
Nostrでは何ができるか
さて、Nostrにおける具体的なクライアントやリレーの実装に関する詳細は、NIP（Nostr Implementation Possibilities）という文書で示されています。これらの各セクションを読み解くことで、Nostrを用いて実現できることの概要を知ることができます。
もちろん、これらは実際にプロトコルを実装したクライアントとリレーを使わなければ利用できません。どのようなクライアントからNostrに参加するか決めるために、各クライアントの比較表を参照できます。
NIP-01: 基本的なプロトコル
Nostrでは、クライアントとリレーがユーザーの署名付きイベントやその他のリクエストをJSON形式でやり取りします。クライアントはイベントの送信や特定のユーザーについての購読リクエストを送ることができ、リレーからは購読リクエストに応じた各種通知や必要なメッセージを送信できます。
NIP-02: フォローリスト
Nostrでは、クライアントからリレーに署名付きのフォローリストを送信できます。このイベントは公開鍵を知っていれば取得できるため、従来のSNSにおける公開フォローと似ています。これにより、別のクライアントでログインした際にフォローリストを復元したり、ユーザーとリレーの対応関係を他のユーザーに提示することが可能です。
NIP-04: 暗号化済みダイレクトメッセージ
Nostrはユーザーの持つ秘密鍵と公開鍵に基づくシステムなので、受信者の公開鍵と送信者の秘密鍵を用いて自然に暗号化済みダイレクトメッセージを転送できます。
NIP-05: DNSを用いた公開鍵のマッピング
Nostrでは、RFC 8615などで定義されている .well-known ディレクトリを用いて local-part@example.com 形式のIDを宣言できます（例: @ama.ne.jp）。その実体はローカルパート部と公開鍵をマッピングしたシンプルなJSONであり、静的ファイルを1つ置くだけで完了するものです。
これは、連合型SNSの項で述べたIDにドメインを含める取り組みのように見えますが、実際には公開鍵で識別されており、このIDは単に人間から見やすくするためのラベルにすぎません。IDが公開鍵を示すのではなく、公開鍵のオプショナルなニックネームとしてIDが存在します。当該NIPにも、このIDではなく公開鍵に従うよう明示されています。
NIP-08: メンション
投稿に対するメンションを処理できるようにします。
NIP-09: イベントの削除
ユーザーが発行したイベントを削除できるようにします。削除されたイベントの取り扱いは各クライアントに任されており、元の投稿を完全に隠したり、二度と読めないようにすることを保証するものではありません。
NIP-25: リアクション
投稿に対して + または - 、あるいは絵文字でリアクションを送信できるようにします。
NIP-28: 公開チャット
フォーラムやコミュニティのような特定の議論の場として使用できるチャネルを作成します。各クライアントの比較表によれば、多くのクライアントではまだサポートされていないようです。
おわりに
この記事では、Nostrがこれまでの中央集権型・非中央集権型SNSに対してどのような立ち位置にいるか、現状どのような機能を利用できるかについて示しました。Nostrの全体像について把握したら、いつでも好きなクライアントを選んでネットワークに参加できます。