mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-22 16:35:52 -05:00
Merge pull request #155 from VictorieeMan/patch-1
NIP-05: Fixed some typos
This commit is contained in:
commit
2c1ed74c49
6
05.md
6
05.md
|
@ -6,7 +6,7 @@ Mapping Nostr keys to DNS-based internet identifiers
|
|||
|
||||
`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.
|
||||
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.
|
||||
|
||||
Upon seeing that, the client splits the identifier into `<local-part>` and `<domain>` and use these values to make a GET request to `https://<domain>/.well-known/nostr.json?name=<local-part>`.
|
||||
|
||||
|
@ -50,7 +50,7 @@ or with the **optional** `"relays"` attribute:
|
|||
|
||||
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 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.
|
||||
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 the specific 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
|
||||
|
||||
|
@ -76,7 +76,7 @@ Clients may treat the identifier `_@domain` as the "root" identifier, and choose
|
|||
|
||||
### Reasoning for the `/.well-known/nostr.json?name=<local-part>` format
|
||||
|
||||
By adding the `<local-part>` as a query string instead of as part of the path the protocol can support both dynamic servers that can generate JSON on-demand and static servers with a JSON file in it that may contain multiple names.
|
||||
By adding the `<local-part>` as a query string instead of as part of the path, the protocol can support both dynamic servers that can generate JSON on-demand and static servers with a JSON file in it that may contain multiple names.
|
||||
|
||||
### Allowing access from JavaScript apps
|
||||
|
||||
|
|
Loading…
Reference in New Issue
Block a user