reword

1 files changed, 13 insertions, 5 deletions

diff --git a/97.md b/97.md
index 443a002..6de3f77 100644
--- a/97.md
+++ b/97.md
@@ -1,16 +1,16 @@
 NIP-97
 ======
 
-Nostr Login
------------
+Login with Nostr
+----------------
 
 `draft` `optional`
 
-This NIP defines a method for a way for users to prove to apps that they control a certain private key. This can be used to enable login for services like the management panel of image hosts.
+This NIP defines a flow for applications to request from a user that they control a private key for. This enables logging into applications (such as paid relay/media hosting services) without having to use other flows which may be annoying to use or not available. (DM codes, NIP-07 extensions)
 
 ## Login URI
 
-A login URI is defined of the format `nostr+login:<domain>:<identifier>` where `domain` MUST be a valid DNS domain or .onion service. The `identifier` MUST only consist of `A-Z a-z 0-9 _ - .`.
+A login URI is defined of the format `nostr+login:<domain>:<challenge>` where `domain` MUST be a valid DNS domain or .onion service. The `challenge` MUST only consist of `A-Z a-z 0-9 _ - .`.
 
 This login URI can be presented as a clickable link, a QR code or a copyable string.
 
@@ -18,7 +18,15 @@ This login URI can be presented as a clickable link, a QR code or a copyable str
 
 A client that wishes to log in to a service SHOULD display the domain associated with the service to the end user before allowing them to log in to prevent services showing a login string for another service.
 
-After the user approves the login, the client should send a POST request to `/.well-known/nostr-login` to the `domain` with the `i` query parameter set to the `identifier` and a valid NIP-98 authentication header present.
+After the user approves the login, the client should send a POST request to `/.well-known/nostr-login` to the `domain` with the `i` query parameter set to the `challenge` and a valid NIP-98 authentication header present.
+
+The response MUST be a JSON object, with the format:
+```json
+{
+  "status": <"success" or "error">,
+  "message": <OPTIONAL string message to show user in the case of an error>
+}
+```
 
 HTTPS should always be used except for `.onion` services, which should be contacted using HTTP.