Bech32でエンコードされたエンティティ

公開鍵やテキスト投稿などのIDをBech32で表現する仕組み

これのこと↓

人間が読みやすいフォーマットで表現できるという利点があります

npubだったら公開鍵だな、noteだったら投稿だなとわかる

なお、通信するときは内部的に16進文字列が使われ、bech32は使われません

NIP-19はあくまで人間が読みやすいようにするための仕様です

主に使われるもの

npub 公開鍵

nsec 秘密鍵

note テキストノート(テキスト投稿)のID

メタデータをつけたものもある

nprofile プロフィール（公開鍵、リレー）

nevent イベント（イベントのID、リレー、投稿者）

naddr パラメータつき上書き可能イベント(識別子、リレー、投稿者、kind）

nrelay リレー（廃止）

仕様

Bech32形式の文字列を使って、鍵(訳註:公開鍵/秘密鍵)やID、その他の情報をクライアントで表現する方法を定義する。

この形式は、コアプロトコル（注釈:通信の中核をなす仕様）において使われることを意図していない。

ユーザへの表示、コピー＆ペースト、共有、QRコードのレンダリング、データの入力といった用途に限られる。

鍵やIDは、コアプロトコルで実際に利用すべき形式に近い形式となるように、16進文字列かバイナリ形式のいずれかで保存することを推奨する。

鍵とID

混同や混合を防ぐために、秘密鍵や公開鍵、イベントIDは、それぞれ異なるプレフィックスを使う bech32(mでない) 32バイトの文字列としてエンコードする。

bech32エンコードされたキーやIDをNIP-01仕様で定められるイベントの形式やフィルタの中で使うことは意図されていない。

これらは人間に分かりやすい表示と入力のためだけに使われることを意図している。

クライアントは、今のところは今までどおりに16進文字列とnpub形式の両方を受け入れるべきであり、内部的に変換すべきである。

追加のメタデータを含む共有可能な識別子

プロフィールやイベントを共有するときは、リレーの情報を含めたり、他のアプリがそれらをよりかんたんに見つけて表示できるように、アプリは他のメタデータを含むことを選んでも良い。

これらのイベントでは、内容（ "contents" ）は、 TLV (type-length-value, 形式-長さ-値)をバイナリエンコードしたものである。 T と L は1バイト（ uint8 , 例えば0-255の間の数）であり、 V は L で示された長さのバイト列である。

標準化された TLV の種類(type)

0 : special 特別

bech32プレフィックスによって意味が変わる

nprofile では、32バイトのプロフィールの公開鍵

nevent では、32バイトのイベントID

naddr では、参照されるイベントの識別子( d タグ)

（訳注） nrelay はリレーのURLだが、ecee40dで廃止された

1 : relay

nprofile , nevent , naddr で含むことがある、 エンティティ（プロフィールやイベント）に含まれるリレーを見つけやすくする、asciiでエンコードされたデータ。複数回含めてもよい。

これは nrelay には適用されない

2 : author

32バイトのイベント発行者の公開鍵

naddr と nevent 用。 nevent では任意

3 : kind

イベントのkindを表す32ビット符号なし整数(ビッグエンディアン)

naddr と nevent 用。 nevent では任意

例

注意

npub 鍵をNIP-01イベントやNIP-05 JSONレスポンスで使ってはならない(MUST NOT)。16進形式だけがサポートされる。

Bech32形式の文字列のデコード時に認識できない、もしくはサポートしていないTLVがある場合は無視すべきである（エラーを発生させるのではなく）。