highperfocused/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2025-03-29 03:02:07 +01:00
Code Issues Packages Projects Releases Wiki Activity

NostrDomainSystem (NDS)

Browse Source 
NIP-53 is now a Decentralized DNS project as the idea of PETnames and public keys already exists in NIP-02 and I changed the name to NostrDomainSystem (NDS)
This commit is contained in:
LeandroFernandes21 2023-02-01 19:09:45 -03:00 committed by GitHub
parent d6cf2e7604
commit da7dd82672
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 15 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
53.md
View File

@ -1,40 +1,37 @@
NIP-53
======
Nostr-based name registration system
------------------------------------
Nostr-based domain registration system
--------------------------------------
`draft` `optional` `author:leandro21b`
## Name:
NostrNameSystem (NNS)
Kind 50
Nostr Domain System (NDS)
Kind 10000
## 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.
A nostr-based decentralized domain registration system where any user can publish an event where IP or onion addresses are assigned to a domain name, multiple domains can be associated with their respective IPs in the same NDS event, if other users trust the user who made the registration they can configure their device to search from it, other users can copy the domain registration data and republish on their own.
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.
Most Internet users do not have a fixed public IP, so the list referring to a website or relay domain may need to be updated from time to time, for this NDS events must be replaceable according to (NIP-16 Replaceable Events)
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.
If the client finds NDS events from different users with the same domain name but for different IP addresses, the client will ask its respective user which one it trusts, then the client will start following the option the user chooses, then the person who found the different IPs can ask the user who posted that NDS event to fix it.
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.
The owner of a site or relay himself can post an NDS event with a domain and the related IP and if people trust that owner they can accept this NDS event posted by him and so the client and/or browser will look for that address automatically without the need for a third party to assign names to an IP.
## Example:
```json
{
"id": ".i.d.",
"pubkey": ".p.k.",
"created_at": 12345,
"kind": 50,
"id": <id>,
"pubkey": <pubkey>,
"created_at": <created_at>,
"kind": 10000,
"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."
"content": "{\"Domain.Example1\":{\"6\":[\"[xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]:port\"],\"4\":[\"xxx.xxx.xxx.xxx:port\",\"xxx.xxx.xxx.xxx:port\"],\"onion\":[\"xxxxxx.onion\"]},{\"Domain.Example2\":{\"6\":[\"[xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]:port\"],\"onion\":[\"xxxxxx.onion\"]}",
"sig": <sig>
}
```
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