-
Notifications
You must be signed in to change notification settings - Fork 18
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
8 additions
and
27 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,19 +6,11 @@ Nostr鍵をDNSベースのインターネット識別子に結びつける | |
|
||
`final` `optional` | ||
|
||
<<<<<<< HEAD | ||
kind `0` (`metadata`)には[インターネット識別子](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (eメールのようなアドレス) を値として`"nip05"`というキーを指定できる。"インターネット識別子"に対する多種多様な仕様のリンクがあるが、NIP-05は`<local-part>`部分が`a-z0-9-_.`で大文字と小文字を区別しないことを前提としている。 | ||
======= | ||
On events of kind `0` (`user metadata`) one can specify the key `"nip05"` with an [internet identifier](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (an email-like address) as the value. Although there is a link to a very liberal "internet identifier" specification above, NIP-05 assumes the `<local-part>` part will be restricted to the characters `a-z0-9-_.`, case-insensitive. | ||
>>>>>>> upstream/master | ||
kind `0` (`user metadata`)には[インターネット識別子](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (eメールのようなアドレス) を値として`"nip05"`というキーを指定できる。"インターネット識別子"に対する多種多様な仕様のリンクがあるが、NIP-05は`<local-part>`部分が`a-z0-9-_.`で大文字と小文字を区別しないことを前提としている。 | ||
|
||
クライアントは識別子を`<local-part>`と`<domain>`に分けた上でそれらの値で`https://<domain>/.well-known/nostr.json?name=<local-part>`にGET要求を行う。 | ||
|
||
<<<<<<< HEAD | ||
結果として、16進数で表される公開鍵に対応した`"names"`キーを持つ、JSONドキュメントオブジェクトが返されなければならない。指定された`<name>`の公開鍵が`metadata`イベントの`pubkey`と一致する場合、クライアントは与えられた公開鍵が実際にその識別子で照会できると結論付ける。 | ||
======= | ||
The result should be a JSON document object with a key `"names"` that should then be a mapping of names to hex formatted public keys. If the public key for the given `<name>` matches the `pubkey` from the `user's metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier. | ||
>>>>>>> upstream/master | ||
結果として、16進数で表される公開鍵に対応した`"names"`キーを持つ、JSONドキュメントオブジェクトが返されなければならない。指定された`<name>`の公開鍵が`user's metadata`イベントの`pubkey`と一致する場合、クライアントは与えられた公開鍵が実際にその識別子で照会できると結論付ける。 | ||
|
||
### 例 | ||
|
||
|
@@ -68,35 +60,24 @@ The result should be a JSON document object with a key `"names"` that should the | |
## メモ | ||
|
||
<<<<<<< HEAD | ||
### クライアントはNIP-05アドレスでなく常に公開鍵をフォローする必要がある。 | ||
======= | ||
### Identification, not verification | ||
### 識別する、検証はしない | ||
|
||
The NIP-05 is not intended to _verify_ a user, but only to _identify_ them, for the purpose of facilitating the exchange of a contact or their search. | ||
Exceptions are people who own (e.g., a company) or are connected (e.g., a project) to a well-known domain, who can exploit NIP-05 as an attestation of their relationship with it, and thus to the organization behind it, thereby gaining an element of trust. | ||
NIP-05はユーザーを_検証_するためではなく、連絡先の交換や検索を容易にするために_識別_することを目的としている。 | ||
例外は、有名なドメインを所有する、 (企業など) あるいは関係する人 (プロジェクトなど) であり、NIP-05をそのドメインとの関係、ひいてはその背後にある組織との関係を証明するものとして利用でき、信用の要素を得ることができる。 | ||
|
||
### User discovery implementation suggestion | ||
### ユーザー発見実装の提案 | ||
|
||
A client can use this to allow users to search other profiles. If a client has a search box or something like that, a user may be able to type "[email protected]" there and the client would recognize that and do the proper queries to obtain a pubkey and suggest that to the user. | ||
クライアントはこれをユーザーが他のプロフィールの検索で使えるようにできる。クライアントが検索ボックスなどを持っている場合、そこに"[email protected]"と入力でき、クライアントはそれを識別して適切なクエリで公開鍵を取得し、ユーザーに提案できる。 | ||
|
||
### Clients must always follow public keys, not NIP-05 addresses | ||
>>>>>>> upstream/master | ||
### クライアントはNIP-05アドレスでなく常に公開鍵をフォローする必要がある。 | ||
|
||
例えば、もし公開鍵`abc…def`をもった`[email protected]`を見つけて、ユーザーがそのプロフィールをフォローすることにした際、クライアントは`[email protected]`ではなく`abc…def`を第一参照先にする必要がある。何らかの理由で、将来`https://bob.com/.well-known/nostr.json?name=bob`が公開鍵`1d2...e3f`を返すようになった場合でもクライアントはフォロー済みユーザーリストで`abc...def`を置き換えてはならない。但し、そのユーザーの”[email protected]”は無効な`”nip05”`プロパティとなるため、表示を止めるべきである。 | ||
|
||
### 公開鍵は16進数形式の必要がある。 | ||
|
||
鍵は16進数の形式で返される必要がある。NIP-19`npub`形式はこのNIPではなく、クライアントUIでの表示にのみ使用される。 | ||
|
||
<<<<<<< HEAD | ||
### ユーザー発見実装の提案 | ||
|
||
クライアントはこれをユーザーが他のプロフィールの検索で使えるようにできる。クライアントが検索ボックスなどを持っている場合、そこに"[email protected]"と入力でき、クライアントはそれを識別して適切なクエリで公開鍵を取得し、ユーザーに提案できる。 | ||
|
||
### ドメインのみを識別子として表示する | ||
======= | ||
### Showing just the domain as an identifier | ||
>>>>>>> upstream/master | ||
|
||
クライアントは`_@domain`識別子を”ルート”識別子として扱い、`<domain>`のみを表示できる。例えば、Bobが`bob.com`を所有している場合、`[email protected]`のような冗長な識別子を望まないかもしれない。代わりに、`_bob.com`を使用してNostrクライアントが如何なる目的でも単に`bob.com`として扱い、表示することを期待できる。 | ||
|
||
|