mirror of
https://github.com/nostr-protocol/nips.git
synced 2025-05-31 18:21:04 +02:00
Add files via upload
This commit is contained in:
parent
8362ff8f79
commit
93e23ce419
39
53.md
Normal file
39
53.md
Normal file
@ -0,0 +1,39 @@
|
||||
NIP-53
|
||||
======
|
||||
|
||||
Nostr-based name registration system
|
||||
------------------------------------
|
||||
|
||||
`draft` `optional` `author:leandro21b`
|
||||
|
||||
## Name:
|
||||
|
||||
Nostr Name System (NNS)
|
||||
Kind 50
|
||||
|
||||
## Description:
|
||||
|
||||
The idea is a nostr-based name registration system, every user can post a name and assign it to a public key, event id, IP address or onion, etc. if other users trust that user who made the registration, they can accept NNS registries from that user and configure your client to search from that user, this can be used for you to find new users on the network without needing the public key, can be used to find an event, can be used as a decentralized DNS, etc. the data is distributed in several relays at the same time and this prevents that, if the user stops updating the NNS list, the data cease to exist, although this theoretically seems to be centralized in a name registration provider user, in practice anyone can provide this service and more than one user can have a copy of the name registration data, the idea is to make it as distributed as possible.
|
||||
|
||||
If it happens that 2 people who posted an NNS event have assigned the same name but for different public keys or IP addresses, the client will ask its respective user which one it trusts and the client will start to base itself on the option that the user chooses, then the person who found different keys or IPs can ask the user who published that NNS to correct it.
|
||||
|
||||
Another alternative that is already used by some nostr clients is when you follow someone it saves the username automatically and thus displays it when you search for it without having to put the public key of that user every time, this concept can also be applied to domains so that you are not dependent on a centralized DNS server.
|
||||
|
||||
Most Internet users do not have a fixed public IP, so the list referring to a website domain may need to be updated from time to time, for this purpose these NNS events will work similarly to kind 3, in case there is an update of an IP related to a domain, the user who posted the NNS event will be able to update the corresponding IP and the most recent event will always be seen by the relays as the correct one and will replace the previous one, as in kind 3.
|
||||
|
||||
The owner of a site himself can post a NNS event with a domain and the related IP and if people trust the owner of a site they will be able to accept this NNS event posted by him and so the client and/or the browser will automatically search for that address without the need for a third party to assign names to an IP or public key.
|
||||
|
||||
## Example:
|
||||
|
||||
```json
|
||||
{
|
||||
"id": ".i.d.", "pubkey": ".p.k.",
|
||||
"created_at": 12345,
|
||||
"kind": 50,
|
||||
"tags": [],
|
||||
"content": "{\"Domain.Example\":{\"6\":[\"[xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]:port\"],\"4\":[\"111.111.111.111:port\",\"222.222.222.222:port\"],\"onion\":[\"xxxxxx.onion\"]},{\"@userexample\":\"npubxxxx\"}",
|
||||
"sig": ".s.g."
|
||||
}
|
||||
```
|
||||
|
||||
Another suggestion is that in case a site has a dedicated nostr profile it can put this domain and IP data directly in the profile-medatada kind 0
|
Loading…
x
Reference in New Issue
Block a user