Kind 5950: NIP-05 Name Registration

kinds/5950.md

@@ -0,0 +1,156 @@
+---
+layout: default
+title: NIP-05 Name Registration
+description: Request a Nostr username
+---
+
+Users can request usernames in a flexible way, either because the client knows that specific names are available, or because DVMs will respond with suggestions to the user's input.
+
+# Discovery
+
+DVMs may make make a list of domains available by publishing a NIP-89 *application handler* event, including any number of `domain` tags:
+
+```js
+{
+  "kind": 31990,
+  "tags": [
+    ["d", <handler-id>],
+    ["k", "5950"],
+    ["domain", "gyroid.party"],
+    ["domain", "spooky.christmas"],
+    ["domain", "slime.church"]
+  ]
+}
+```
+
+Clients wishing to discover domains should query for kind `31990` events where the `k` tag is `5950`, and then collect the `domain` tags.
+
+To verify the domain belongs to a DVM, the identity provider MUST assign the root NIP-05 name (`_@<domain>`) to the DVM's pubkey. Clients can then do a NIP-05 lookup to verify domain ownership.
+
+To check if the user's chosen name is available, clients should do a NIP-05 lookup for it before sending a job request.
+
+# Input
+
+Desired NIP-05 username requested by the user.
+It MAY include the domain (eg `[email protected]`) or just the localpart (eg `alex`), depending on the design of the client.
+
+If the input includes a domain, the event SHOULD include a `p` tag of a specific DVM's pubkey.
+If only the localpart is included, the client is relying on DVMs to suggest the chosen name on available domains.
+
+```js
+[ "i", "<nip05>", "text" ]
+```
+
+## Example request (specific domain)
+
+```js
+{
+  kind: 5950,
+  tags: [
+    ["i", "[email protected]", "text"],
+    ["p", "66b4fefa1d29b0be53dbe0012f2d0461b3a03dcdbddd81fad2191261caa2104d"],
+  ]
+}
+```
+
+## Example request (any domain)
+
+```js
+{
+  kind: 5950,
+  tags: [
+    ["i", "alex", "text"],
+  ]
+}
+```
+
+# Params
+
+- `relays` - array of relay URLs to be listed in the NIP-05 response.
+
+```js
+{
+  kind: 5950,
+  tags: [
+    ["i", "alex", "text"],
+    ["param", "relays", "wss://relay.mostr.pub/", "wss://relay.snort.social/"],
+  ]
+}
+```
+
+# Output
+
+The NIP-05 username (with domain, eg `[email protected]`) that was registered by the DVM for the user.
+
+## Example response
+
+```js
+{
+  kind: 6950,
+  content: "[email protected]",
+  tags: [
+    ["request", "\"{...}\""],
+    ["i", "[email protected]", "text"],
+    ["e", "abcd..."],
+    ["p", "ef01..."],
+  ],
+}
+```
+
+# Feedback
+
+The DVM may reject the request due to the name being taken, or it may request payment.
+Below are some possible feedback statuses:
+
+- `["status", "error", "Invalid name: !@#$"]`
+- `["status", "error", "Name already taken: [email protected]"]`
+- `["status", "error", "Unsupported domain: google.com"]`
+- `["status", "error", "Forbidden user: _"]`
+- `["status", "payment-required"]`
+
+Example event:
+
+```js
+{
+  kind: 7000,
+  tags: [
+    ["status", "error", "Name already taken: [email protected]"],
+    ["e", "abcd..."],
+    ["p", "ef01..."],
+  ]
+}
+```
+
+The DVM may also suggest different names to the user, using either the same localpart or the same domain (depending on the user's input), or some variation of it.
+
+When the `status` is set to `partial`, the content will be a JSON-encoded array of suggestions:
+
+```js
+{
+  kind: 7000,
+  content: "[\"[email protected]\",\"[email protected]\",\"[email protected]\"]",
+  tags: [
+    ["status", "partial"],
+    ["e", "abcd..."],
+    ["p", "ef01..."]
+  ]
+}
+```
+
+To accept any of these names, the client should send a new kind `5950` job request event with the chosen name.
+
+# Updating relay URLs
+
+If the user has already registered a name, they can request the DVM to update the relay URLs in the NIP-05 response by sending a new kind `5950` job request event with the existing name.
+
+```js
+{
+  kind: 5950,
+  tags: [
+    ["i", "[email protected]", "text"],
+    ["param", "relays", "wss://relay.damus.io/"],
+  ]
+}
+```
+
+The DVM should recognize that the user already owns the name and update the data accordingly, and then respond with a kind `6950` event. The format of events in this flow is no different from the initial registration flow.