Translate NIP-42 partially

42.md

@@ -1,32 +1,30 @@
-NIP-42
-======
+# NIP-42
 
-Authentication of clients to relays
------------------------------------
+## リレーに対するクライアントの認証
 
 `draft` `optional`
 
-This NIP defines a way for clients to authenticate to relays by signing an ephemeral event.
+この NIP はクライアントが一時的なイベントに署名することでリレーに対して認証する方法を定義する。
 
-## Motivation
+## 動機
 
-A relay may want to require clients to authenticate to access restricted resources. For example,
+リレーは、制限されたリソースにアクセスしようとするクライアントに認証を要求したくなる場合がある。例えば:
 
-  - A relay may request payment or other forms of whitelisting to publish events -- this can naïvely be achieved by limiting publication to events signed by the whitelisted key, but with this NIP they may choose to accept any events as long as they are published from an authenticated user;
-  - A relay may limit access to `kind: 4` DMs to only the parties involved in the chat exchange, and for that it may require authentication before clients can query for that kind.
-  - A relay may limit subscriptions of any kind to paying users or users whitelisted through any other means, and require authentication.
+- リレーはクライアントからのイベントの送信に対して支払いまたはその他の形式のホワイトリスト登録を要求する可能性がある。 -- これは素朴には送信できるイベントをホワイトリストに登録された鍵で署名されたもののみに制限することで達成されるが、この NIP を使用すれば、認証されたユーザから送信されたイベントであればどのようなイベントでもリレーはそれを受け入れるかを選択できる。
+- リレーは `kind: 4` DM へのアクセスをそれを交換している当事者のみに制限する可能性があり、そしてそのためにクラアントが同 kind をクエリする前に認証を要求したいかもしれない。
+- リレーはあらゆる種類の購読を課金ユーザまたは他の何らかの手段でホワイトリスト登録されたユーザのみに限定する可能性があり、そのために認証が必要かもしれない。
 
-## Definitions
+## 定義
 
 ### New client-relay protocol messages
 
-This NIP defines a new message, `AUTH`, which relays CAN send when they support authentication and clients can send to relays when they want to authenticate. When sent by relays the message has the following form:
+この NIP は新しいメッセージ `AUTH` を定義する。このメッセージを、リレーは認証をサポートするときクライアントに、クライアントは認証したいときリレーに送信してもよい (CAN)。リレーによって送信された場合、メッセージは以下の形式を取る:
 
 ```json
 ["AUTH", <challenge-string>]
 ```
 
-And, when sent by clients, the following form:
+クライアントによって送信された場合は、以下の形式を取る:
 
 ```json
 ["AUTH", <signed-event-json>]
@@ -36,7 +34,7 @@ And, when sent by clients, the following form:
 
 ### Canonical authentication event
 
-The signed event is an ephemeral event not meant to be published or queried, it must be of `kind: 22242` and it should have at least two tags, one for the relay URL and one for the challenge string as received from the relay. Relays MUST exclude `kind: 22242` events from being broadcasted to any client. `created_at` should be the current time. Example:
+署名されたイベント (`<signed-event-json>`) は送信またはクエリされることを意図していない一時的なイベントであり、`kind: 22242` でなければならず、かつ少なくとも 2 つのタグ -- すなわちひとつにリレーの URL を、そしてもうひとつにリレーから受け取ったチャレンジ文字列 (`<challenge-string>`) を持っているべきである。リレーは `kind: 22242` イベントをクライアントへのブロードキャストから除かなければならない (MUST)。`created_at` は現在時刻であるべきだ。例えば:
 
 ```json
 {
@@ -94,12 +92,12 @@ client: ["EVENT", {"id": "012345...", ...}]
 relay: ["OK", "012345...", true, ""]
 ```
 
-## Signed Event Verification
+## 署名されたイベントの検証
 
-To verify `AUTH` messages, relays must ensure:
+`AUTH` メッセージを検証するため、リレーは以下を確認しなければならない:
 
-  - that the `kind` is `22242`;
-  - that the event `created_at` is close (e.g. within ~10 minutes) of the current time;
-  - that the `"challenge"` tag matches the challenge sent before;
-  - that the `"relay"` tag matches the relay URL:
-    - URL normalization techniques can be applied. For most cases just checking if the domain name is correct should be enough.
+- その `kind` が `22242` である
+- そのイベントの `created_at` が現在時刻に近い (例: 10 分以内)
+- その `"challenge"` タグの値が以前送ったチャレンジと合致する
+- その `"relay"` タグの値がリレーの URL と合致する
+  - URL 正規化技術が適用されている可能性がある。ほとんどの場合、ドメイン名が正しいかどうかを確認するだけで十分である。