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.