Skip to content

Latest commit

 

History

History
104 lines (66 loc) · 7.15 KB

05.md

File metadata and controls

104 lines (66 loc) · 7.15 KB
Raw

NIP-05

Nostr鍵をDNSベースのインターネット識別子に結びつける

final optional

kind 0 (user metadata)にはインターネット識別子 (eメールのようなアドレス) を値として"nip05"というキーを指定できる。"インターネット識別子"に対する多種多様な仕様のリンクがあるが、NIP-05は<local-part>部分がa-z0-9-_.で大文字と小文字を区別しないことを前提としている。

クライアントは識別子を<local-part>と<domain>に分けた上でそれらの値でhttps://<domain>/.well-known/nostr.json?name=<local-part>にGET要求を行う。

結果として、16進数で表される公開鍵に対応した"names"キーを持つ、JSONドキュメントオブジェクトが返されなければならない。指定された<name>の公開鍵がuser metadataイベントのpubkeyと一致する場合、クライアントは与えられた公開鍵が実際にその識別子で照会できると結論付ける。

例

クライアントが下記のようなイベントを見た時。

{
  "pubkey": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9",
  "kind": 0,
  "content": "{\"name\": \"bob\", \"nip05\": \"bob@example.com\"}"
  // other fields...
}

https://example.com/.well-known/nostr.json?name=bobのようにGET要求を行い、次のような応答を得る。

{
  "names": {
    "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
  }
}

あるいは、推奨される"relays"属性が追加される場合は次の通り。

{
  "names": {
    "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
  },
  "relays": {
    "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [ "wss://relay.example.com", "wss://relay2.example.com" ]
  }
}

上記の例のように公開鍵が"names"で与えられたものと一致する場合、関連付けが正しいことを意味し、"nip05"識別子は有効なものとして表示できる。

推奨される"relays"属性には、公開鍵をプロパティ名、リレーURLの配列を値に持つオブジェクトを含められる。存在する場合、クライアントが特定のユーザーを見つけられるリレーを知るために使用可能である。クエリ文字列に基づいて動的に/.well-known/nostr.jsonファイルを提供するWebサーバーは、利用可能な場合、同じ応答で提供する名前に於けるリレーデータも提供すべきである (SHOULD)。

NIP-05識別子からユーザーを見つける

クライアントは_インターネット識別子_からユーザーの公開鍵を見つける機能を実装しても良い。流れは上記の逆である。まず、クライアントは_well-known_URLを参照して、そこからユーザーの公開鍵を取得する。その後ユーザーのkind0の取得を試みて、"nip05"と合致するか確認する。

メモ

識別する、検証はしない

NIP-05はユーザーを_検証_するためではなく、連絡先の交換や検索を容易とするために_識別_することを目的としている。 例外は有名なドメインを所有する (企業等) あるいは関係する人 (プロジェクト等) であり、NIP-05をそのドメインとの関係、ひいてはその背後にある組織との関係を証明するものとして利用でき、信用の要素を得ることができる。

ユーザー発見実装の提案

クライアントはこれをユーザーが他のプロフィールの検索で使えるようにできる。クライアントが検索ボックスなどを持っている場合、そこに"bob@example.com"と入力でき、クライアントはそれを識別して適切なクエリで公開鍵を取得し、ユーザーに提案できる。

クライアントはNIP-05アドレスでなく常に公開鍵をフォローする必要がある。

例えば、もし公開鍵abc…defをもったbob@bob.comを見つけて、ユーザーがそのプロフィールをフォローすることにした際、クライアントはbob@bob.comではなくabc…defを第一参照先にする必要がある。何らかの理由で、将来https://bob.com/.well-known/nostr.json?name=bobが公開鍵1d2...e3fを返すようになった場合でもクライアントはフォロー済みユーザーリストでabc...defを置き換えてはならない。但し、そのユーザーの”bob@bob.com”は無効な”nip05”プロパティとなるため、表示を止めるべきである。

公開鍵は16進数形式の必要がある。

鍵は16進数の形式で返される必要がある。NIP-19npub形式はこのNIPではなく、クライアントUIでの表示にのみ使用される。

ドメインのみを識別子として表示する

クライアントは_@domain識別子を”ルート”識別子として扱い、<domain>のみを表示できる。例えば、Bobがbob.comを所有している場合、bob@bob.comのような冗長な識別子を望まないかもしれない。代わりに、_bob.comを使用してNostrクライアントが如何なる目的でも単にbob.comとして扱い、表示することを期待できる。

/.well-known/nostr.json?name=<local-part>書式の理由

パスの代わりにクエリ文字列として<local-part>を追加することで、このプロトコルはオンデマンドでJSONを生成できる動的なサーバーと、複数の名前を含むJSONファイルを置く静的なサーバーの両方に対応できる。

JavaScriptアプリへのアクセス許可

JavaScript NostrアプリはブラウザのCORSポリシーによってユーザーのドメインで/.well-known/nostr.jsonへのアクセスを妨げられる可能性がある。CORSがJSに資源を読み込ませなかった場合、JSプログラムはそれを存在しない資源と同じネットワーク障害と見做すため、バニラJSアプリが障害はCORSの問題で引き起こされたことを伝える方法は無い。JS Nostrアプリは/.well-known/nostr.jsonファイルを要求した時ネットワーク障害に遭遇したら、サーバのCORSポリシーを確認することをユーザに勧めた方がいいかもしれない。

$ curl -sI https://example.com/.well-known/nostr.json?name=bob | grep -i ^Access-Control
Access-Control-Allow-Origin: *

ユーザーは最新のブラウザで実行されるバニラJSアプリが検証できるよう、/.well-known/nostr.jsonをAccess-Control-Allow-Origin: *のHTTPヘッダ付きで提供しなければならない。

セキュリティ上の制約

/.well-known/nostr.json`のエンドポイントはHTTPリダイレクトを返してはならない (MUST)。

取得する側は/.well-known/nostr.jsonからのHTTPリダイレクトを無視しなければならない (MUST)。