merge NIP-35 into NIP-05.

This commit is contained in:
fiatjaf 2023-01-04 10:34:24 -03:00
parent 4472f9bbd9
commit 8c3c421715
No known key found for this signature in database
GPG Key ID: BAD43C4BE5C1A3A1
3 changed files with 18 additions and 47 deletions

21
05.md
View File

@ -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"
}
}
```
````
That will mean everything is alright.
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.
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

43
35.md
View File

@ -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.

View File

@ -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)