NIPsは絶対守るべきNostrの仕様書？
Nostrを使って何か作ろうとする時に、まずは仕様を確認しようとしますよね。
その際に参照するのはNIPsになると思います。
ではNIPsというのは絶対に守られるべき掟なのか？というと、そこまでの権威性は無いように見受けられます。
Damusは kind:1 以外のイベントを kind:6 でリポストしちゃうし(NIP-18違反)。
Amethystは kind:1 を Markdown で解釈しようとするし(NIP-10違反)。
本稿では、現状採用されているNIPsの仕様のすべてがそもそも広く賛同されているわけではないんだよ、ということを、
具体的な事例を取り上げていくつか紹介していきたいと思います。
具体的な事例
kind:1 へのリプライは kind:1111 になる？
これは最近動きがある仕様なので最初に紹介しておきましょう。
NIP-22 では kind:1 以外のイベントへのコメントを kind:1111 で行うよう定められていますが、これを kind:1 へも適用しようという動きがあります。
前者は既にmerge済、後者も時間の問題のように見えます。
これは実用的にも仕様的にも美しいと思う反面、変更が破壊的すぎるとも感じられます。
Damusユーザーは他者からのリプライが見えなくなる時代になっていくのかもしれません。
魚拓リポスト(NIP-18)
魚拓リポストについては以前記事としてまとめました。
これについては明確に賛否が分かれていて、海外にも魚拓リポストに対して否定的な開発者もいます。
みなさんもぜひ自分自身でその是非を考えてみましょう。
ファイルストレージの仕様 NIP-96 vs Blossom(NIP-B7)
画像をアップロードする先のアップローダーはみなさんは何をお使いですか？
クライアントで投稿する際にファイルのアップロード機能が付いている場合が多いと思いますが、そのアップローダーは NIP-96 か Blossom と呼ばれる仕様のいずれかに対応しています。
NIP-96 は現在 deprecated とされています。
NIP-96 はSNS的な使用に特化した仕様、BlossomはNostrの思想に近い、耐障害性・耐検閲性を重視した仕様、とざっくり覚えておけば十分です。
アップロードされたファイルが誰のものであるかを気にする必要がないということは、誰からの削除依頼も受け付ける必要がない、ということのように読めますね。
魚拓リポストと同様に賛否が分かれそうな思想です。
パブリックチャット NIP-28 vs(?) リレーベース・グループ NIP-29
これらはそもそも全然別物なのですがなぜか比較され、 NIP-28 は deprecated とされています。
アウトボックスモデル(NIP-65)
これは別に対立しているとかではなく、仕様としてそういうものがあって、サポートしているクライアントとしていないクライアントがあるねー、くらいなものですが、一応紹介しておきます。
まとめ
Nostrの仕様を確認するには当然NIPsを見るしかないのですが、中にはかなり思想が偏ったものもあり、広く賛同されているわけではないものもあります。
また実際広く使われているクライアントがNIPsを遵守しているわけでもありません。
あなたが仮にLLMにNIPsを読ませてクライアントを作成させた場合、NIPsに忠実なクライアントが完成するでしょう。
しかしそれは思想が偏っていたり、他者に広く不評を買っていたりする仕様になる可能性があります。
そもそもあなた自身が好きになれるクライアントにならない可能性もあります。
上記のような事例を踏まえ、NIPsを盲目的に信奉せず、あなた自身が望む仕様とは何かを常に意識することで、より良いクライアントを生み出していきましょう。
- Reference: https://github.com/nostr-protocol/nips
- Reference: https://github.com/nostr-protocol/nips/pull/2358
- Reference: https://github.com/nostr-protocol/nips/pull/2447
- Reference: https://github.com/nostr-protocol/nips/issues/2370
- Reference: https://zenn.dev/nikolat/articles/b5936ab157fcf7
Write a comment