-
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.
Merge pull request #15 from s3-odara/NIP-05
NIP-05の翻訳
- Loading branch information
Showing
1 changed file
with
30 additions
and
29 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 |
|---|---|---|
| @@ -1,20 +1,21 @@ | ||
| NIP-05 | ||
| ====== | ||
|
|
||
| Mapping Nostr keys to DNS-based internet identifiers | ||
| Nostr鍵をDNSベースのインターネット識別子に結びつける | ||
| ---------------------------------------------------- | ||
|
|
||
| `final` `optional` | ||
|
|
||
| On events of kind `0` (`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. | ||
| kind `0` (`metadata`)には[インターネット識別子](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (eメールのようなアドレス) を値として`"nip05"`というキーを指定できます。"インターネット識別子"に対する多種多様な仕様のリンクがありますが、NIP-05は`<local-part>`部分が`a-z0-9-_.`で大文字と小文字を区別しないことを前提としています。 | ||
|
|
||
| Upon seeing that, the client splits the identifier into `<local-part>` and `<domain>` and use these values to make a GET request to `https://<domain>/.well-known/nostr.json?name=<local-part>`. | ||
| クライアントは識別子を`<local-part>`と`<domain>`に分けた上でそれらの値で`https://<domain>/.well-known/nostr.json?name=<local-part>`にGETリクエストを行います。 | ||
|
|
||
| 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 `metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier. | ||
| 結果として、16進数で表される公開鍵に対応した`"names"`キーを持つ、JSONドキュメントオブジェクトが返されなければなりません。指定された`<name>`の公開鍵が`metadata`イベントの`pubkey`と一致する場合、クライアントは与えられた公開鍵が実際にその識別子で照会できると結論付けます。 | ||
|
|
||
| ### Example | ||
| ### 例 | ||
|
|
||
| If a client sees an event like this: | ||
|
|
||
| クライアントが下記のようなイベントを見た時。 | ||
|
|
||
| ```json | ||
| { | ||
|
|
@@ -25,7 +26,7 @@ If a client sees an event like this: | |
| } | ||
| ``` | ||
|
|
||
| It will make a GET request to `https://example.com/.well-known/nostr.json?name=bob` and get back a response that will look like | ||
| `https://example.com/.well-known/nostr.json?name=bob`のようにGETリクエストを行い、次のような応答を得ます。 | ||
|
|
||
| ```json | ||
| { | ||
|
|
@@ -35,7 +36,7 @@ It will make a GET request to `https://example.com/.well-known/nostr.json?name=b | |
| } | ||
| ```` | ||
|
|
||
| or with the **optional** `"relays"` attribute: | ||
| あるいは、**任意**の`"relays"`属性が追加される場合は次の通りです。 | ||
|
|
||
| ```json | ||
| { | ||
|
|
@@ -48,51 +49,51 @@ or with the **optional** `"relays"` attribute: | |
| } | ||
| ```` | ||
|
|
||
| If the pubkey matches the one given in `"names"` (as in the example above) that means the association is right and the `"nip05"` identifier is valid and can be displayed. | ||
| 上記の例のように公開鍵が`"names"`で与えられたものと一致する場合、関連付けが正しいことを意味し、`"nip05"`識別子は有効なものとして表示できます。 | ||
|
|
||
| The optional `"relays"` attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays the specific user may be found. Web servers which serve `/.well-known/nostr.json` files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available. | ||
| 任意の`"relays"`属性には、公開鍵をプロパティ名、リレーURLの配列を値に持つオブジェクトを含められます。存在する場合、クライアントが特定のユーザーを見つけられるリレーを知るために使用できます。クエリ文字列に基づいて動的に`/.well-known/nostr.json`ファイルを提供するWebサーバーは、利用可能な場合、同じ応答で提供する名前に於けるリレーデータも提供すべきです (SHOULD)。 | ||
|
|
||
| ## Finding users from their NIP-05 identifier | ||
| ## NIP-05識別子からユーザーを見つける | ||
|
|
||
| A client may implement support for finding users' public keys from _internet identifiers_, the flow is the same as above, but reversed: first the client fetches the _well-known_ URL and from there it gets the public key of the user, then it tries to fetch the kind `0` event for that user and check if it has a matching `"nip05"`. | ||
| クライアントは_インターネット識別子_からユーザーの公開鍵を見つける機能を実装しても良いです。流れは上記の逆です。まず、クライアントは_well-known_URLを参照して、そこからユーザーの公開鍵を取得します。その後ユーザーのkind`0`の取得を試みて、`"nip05"`と合致するか確認します。 | ||
|
|
||
| ## Notes | ||
| ## メモ | ||
|
|
||
| ### Clients must always follow public keys, not NIP-05 addresses | ||
| ### クライアントはNIP-05アドレスでなく常に公開鍵をフォローする必要があります。 | ||
|
|
||
| For example, if after finding that `[email protected]` has the public key `abc...def`, the user clicks a button to follow that profile, the client must keep a primary reference to `abc...def`, not `[email protected]`. If, for any reason, the address `https://bob.com/.well-known/nostr.json?name=bob` starts returning the public key `1d2...e3f` at any time in the future, the client must not replace `abc...def` in his list of followed profiles for the user (but it should stop displaying "[email protected]" for that user, as that will have become an invalid `"nip05"` property). | ||
| 例えば、もし公開鍵`abc…def`をもった`[email protected]`を見つけて、ユーザーがそのプロフィールをフォローすることにした際、クライアントは`[email protected]`ではなく`abc…def`を第一参照先にする必要があります。何らかの理由で、将来`https://bob.com/.well-known/nostr.json?name=bob`が公開鍵`1d2...e3f`を返すようになった場合でもクライアントはフォロー済みユーザーリストで`abc...def`を置き換えてはなりません。但し、そのユーザーの”[email protected]”は無効な`”nip05”`プロパティとなるため、表示を止めるべきです。 | ||
|
|
||
| ### Public keys must be in hex format | ||
| ### 公開鍵は16進数形式の必要があります。 | ||
|
|
||
| Keys must be returned in hex format. Keys in NIP-19 `npub` format are only meant to be used for display in client UIs, not in this NIP. | ||
| 鍵は16進数の形式で返される必要があります。NIP-19`npub`形式はこのNIPではなく、クライアントUIで表示するためだけにあります。 | ||
|
|
||
| ### User Discovery implementation suggestion | ||
| ### ユーザー発見実装の提案 | ||
|
|
||
| A client can also 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]"と入力でき、クライアントはそれを識別して適切なクエリで公開鍵を取得し、ユーザーに提案できます。 | ||
|
|
||
| ### Showing just the domain as an identifier | ||
| ### ドメインのみを識別子として表示する | ||
|
|
||
| Clients may treat the identifier `_@domain` as the "root" identifier, and choose to display it as just the `<domain>`. For example, if Bob owns `bob.com`, he may not want an identifier like `[email protected]` as that is redundant. Instead, Bob can use the identifier `_@bob.com` and expect Nostr clients to show and treat that as just `bob.com` for all purposes. | ||
| クライアントは`_@domain`識別子を”ルート”識別子として扱い、`<domain>`のみを表示できます。例えば、Bobが`bob.com`を所有している場合、`[email protected]`のような冗長な識別子を望まないかもしれません。代わりに、`_bob.com`を使用してNostrクライアントが如何なる目的でも単に`bob.com`として扱い、表示することを期待できます。 | ||
|
|
||
| ### Reasoning for the `/.well-known/nostr.json?name=<local-part>` format | ||
| ### `/.well-known/nostr.json?name=<local-part>`書式の理由 | ||
|
|
||
| By adding the `<local-part>` as a query string instead of as part of the path, the protocol can support both dynamic servers that can generate JSON on-demand and static servers with a JSON file in it that may contain multiple names. | ||
| パスの代わりにクエリ文字列として`<local-part>`を追加することで、このプロトコルはオンデマンドでJSONを生成できる動的なサーバーと、複数の名前を含むJSONファイルを置く静的なサーバーの両方に対応できます。 | ||
|
|
||
| ### Allowing access from JavaScript apps | ||
| ### JavaScriptアプリへのアクセス許可 | ||
|
|
||
| JavaScript Nostr apps may be restricted by browser [CORS][] policies that prevent them from accessing `/.well-known/nostr.json` on the user's domain. When CORS prevents JS from loading a resource, the JS program sees it as a network failure identical to the resource not existing, so it is not possible for a pure-JS app to tell the user for certain that the failure was caused by a CORS issue. JS Nostr apps that see network failures requesting `/.well-known/nostr.json` files may want to recommend to users that they check the CORS policy of their servers, e.g.: | ||
| JavaScript Nostrアプリはブラウザの[CORS][]ポリシーによってユーザーのドメインで`/.well-known/nostr.json`へのアクセスを妨げられる可能性があります。CORSがJSに資源を読み込ませなかった場合、JSプログラムはそれを存在しない資源と同じネットワーク障害と見做すため、バニラJSアプリが障害はCORSの問題で引き起こされたことを伝える方法はありません。JS Nostrアプリは`/.well-known/nostr.json`ファイルを要求した時ネットワーク障害に遭遇したら、サーバのCORSポリシーを確認することをユーザに勧めた方がいいかもしれません。 | ||
|
|
||
| ```bash | ||
| $ curl -sI https://example.com/.well-known/nostr.json?name=bob | grep -i ^Access-Control | ||
| Access-Control-Allow-Origin: * | ||
| ``` | ||
|
|
||
| Users should ensure that their `/.well-known/nostr.json` is served with the HTTP header `Access-Control-Allow-Origin: *` to ensure it can be validated by pure JS apps running in modern browsers. | ||
| ユーザーは最新のブラウザで実行されるバニラJSアプリが検証できるよう、`/.well-known/nostr.json`を`Access-Control-Allow-Origin: *`のHTTPヘッダ付きで提供しなければなりません。 | ||
|
|
||
| [CORS]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS | ||
|
|
||
| ### Security Constraints | ||
| ### セキュリティ上の制約 | ||
|
|
||
| The `/.well-known/nostr.json` endpoint MUST NOT return any HTTP redirects. | ||
| /.well-known/nostr.json`のエンドポイントはHTTPリダイレクトを返してはなりません (MUST)。 | ||
|
|
||
| Fetchers MUST ignore any HTTP redirects given by the `/.well-known/nostr.json` endpoint. | ||
| 取得する側は`/.well-known/nostr.json`からのHTTPリダイレクトを無視しなければなりません (MUST)。 | ||