diff --git a/05.md b/05.md
index b489b4b..437c637 100644
--- a/05.md
+++ b/05.md
@@ -4,7 +4,7 @@ NIP-05
 Mapping Nostr keys to DNS-based internet identifiers
 ----------------------------------------------------
 
-`final` `optional` `author:fiatjaf`
+`final` `optional` `author:fiatjaf` `author:mikedilger`
 
 On events of kind `0` (`set_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.
 
@@ -33,9 +33,24 @@ It will make a GET request to `https://example.com/.well-known/nostr.json?name=b
     "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
   }
 }
-```
+````
+
+or with the **optional** `"relays"` attribute:
+
+```json
+{
+  "names": {
+    "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
+  },
+  "relays": {
+    "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [ "wss://relay.example.com", "wss://relay2.example.com" ]
+  }
+}
+````
+
+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.
 
-That will mean everything is alright.
+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 a that 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.
 
 ## Finding users from their NIP-05 identifier
 
diff --git a/35.md b/35.md
deleted file mode 100644
index dec9478..0000000
--- a/35.md
+++ /dev/null
@@ -1,43 +0,0 @@
-
-NIP-35
-======
-
-User Discovery
---------------
-
-`draft` `optional` `author:mikedilger`
-
-This NIP extends NIP-05 to facilitate a mechanism of user discovery that provides both public key information and relay information.
-
-This NIP does not modify any data or events within the nostr protocol. It only extends the contents of `https://<domain>/.well-known/nostr.json?name=<local-part>` return values with additional relay information.
-
-With this NIP implemented, clients may then attempt to discover users via email-like addresses (see NIP-05) and potentially find what relays they post to along with their public key.
-
-### nostr.json contents
-
-NIP-05 specifies a `nostr.json` file with contents like this (refer to NIP-05):
-
-```json
-{
-  "names": {
-    "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
-  }
-}
-```
-
-This NIP proposes an optional additional key like this:
-
-````
-{
-  "names": {
-    "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
-  },
-  "relays": {
-    "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [ "wss://relay.example.com", "wss://relay2.example.com" ]
-  }
-}
-````
-
-The `relays` key contains an object with public keys as properties and arrays of relays as values.
-
-Web servers which serve nostr.json files dynamically responding to the query string SHOULD also serve the relays data for any name they serve in the same reply.
diff --git a/README.md b/README.md
index fa5896b..10bb5ef 100644
--- a/README.md
+++ b/README.md
@@ -26,7 +26,6 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 - [NIP-26: Delegated Event Signing](26.md)
 - [NIP-28: Public Chat](28.md)
 - [NIP-33: Parameterized Replaceable Events](33.md)
-- [NIP-35: User Discovery](35.md)
 - [NIP-36: Sensitive Content](36.md)
 - [NIP-40: Expiration Timestamp](40.md)