From 50faceef0965042714e7f50a45b102f35c5231ca Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Wed, 4 Jan 2023 10:24:37 -0300 Subject: [PATCH] clarify `created_at` and auth session duration. --- 42.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/42.md b/42.md index b17aa143..4c884a9a 100644 --- a/42.md +++ b/42.md @@ -43,7 +43,8 @@ WebSocket URL of the relay. `created_at` should be the current time. Example: ``` The client may send an auth message right before performing an action for which it knows authentication will be required -- for example, right -before requesting `kind: 4` chat messages --, or it may do right on connection start or at some other moment it deems best. +before requesting `kind: 4` chat messages --, or it may do right on connection start or at some other moment it deems best. The authentication +is expected to last for the duration of the WebSocket connection. Upon receiving a message from an unauthenticated user it can't fulfill without authentication, a relay may choose to notify the client. For that it can use a `NOTICE` message with a standard prefix `"restricted: "` that is readable both by humans and machines, for example: @@ -62,7 +63,7 @@ or it can return an `OK` message noting the reason an event was not written usin To verify `AUTH` messages, relays must ensure: - - that the `kind` is `22242` - - that the event was recently signed (~10 minutes, by `created_at`) - - that the `content` field matches the relay URL + - that the `kind` is `22242`; + - that the event `created_at` is close (e.g. within ~10 minutes) of the current time; + - that the `content` field matches the relay URL: - URL normalization techniques can be applied. For most cases just checking if the domain name is correct should be enough.