NIP-19
bech32-encoded entities
Bech32でエンコードされたエンティティ
これのこと↓
npub1h0hl3ly5xwes7u5tnrkj5grerknw3e55fwet2f9s66dmglaafv0qkv6sx4
人間が読みやすいフォーマットで表現できるという利点があります
npubだったら公開鍵だな、noteだったら投稿だなとわかる
なお、通信するときは内部的に16進文字列が使われ、bech32は使われません
NIP-19はあくまで人間が読みやすいようにするための仕様です
主に使われるもの
npub 公開鍵
nsec 秘密鍵
メタデータをつけたものもある
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タグ)
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がある場合は無視すべきである（エラーを発生させるのではなく）。