nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-12 23:19:08 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

NIP-53 Improvements

Browse Source
This commit is contained in:
LeandroBitcoiner21 2023-03-24 13:33:31 -03:00 committed by GitHub
parent f7928cfdbc
commit 97dafc5d6e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 39 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
53.md
View File

@ -10,28 +10,52 @@ Nostr-based domain registration system
Nostr Domain System (NDS)
Kind 10000
## Description:
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.
A domain registration system based on nostr where users can create domains associated with their IP addresses and onion, then this data is signed by the user's key and sent to several relays, so that the registrations do not depend on a central server
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)
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.
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.
As IP addresses can change from time to time, domain registration events must be replaceable and therefore are classified as KIND-10002 according to the (NIP-16 Replaceable Events)
## Example:
```json
{
"id": <id>,
"pubkey": <pubkey>,
"created_at": <created_at>,
"kind": 10000,
"tags": [],
"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>
"kind": 10002,
"tags": [
["dr" "Domain1", "ip4:port", "ip6:port", "onion"],
["dr" "Domain2", "ip6:port", "onion"] /* dr = domain register */
],
"content": <content>,
}
```
## Avoiding duplicate registration:
There are several ways to avoid confusion due to the same domain being registered several times, one of them is the "organizing users" who do nothing more than organize a list with several id of ordered registration events, it itself does not register , it only organizes the registration events and in this process it will filter duplicate and malicious registrations, from this list it is possible to arrive at the original registration event that is made by the domain owner and verify the corresponding signature.
## Example:
```json
{
"kind": 10003,
"tags": [
["dro" "domainregistryevent"],
["dro" "domainregistryevent"] /* dro = domain registration organizer */
],
"content": <content>,
}
```
This event should also be replaceable as domain events may need to be changed as stated above, so it is classified as KIND-10003
It is very important not to depend on a single organizing user, although the domain registration itself is not done by them.
## Other ways to avoid duplication:
Even if there are several records of different IPs for the same domain name, the user's device will still be able to filter in different ways for example by seeing the npub of the users who published the record, whether this npub is trusted by the owner of the client or not or also by other users that the client owner knows and trusts, by the creation timestamp of the log event, etc. It is the same logic of differentiating a cloned profile from the original, in this regard reputation is the main defense.
Another way to avoid duplicate names is for relays that adopt the NIP-53 idea to check whether a domain already exists before accepting an NDS event, in which case it is as if each relay were a DNS server, efforts should not be focused on avoiding double registrations on relays since many may not adopt NIP-53, no one should be forced into anything!
If someone registers a domain it is because they want other people to visit their website, the incentive is for the owner of that website to disclose the domain to several well-known organizing users, as well as a user who wants to publish something on the nostr for all to see the incentive is to publish on several known relays, otherwise no one will see the post, so following this logic, the domain owner's incentive is to avoid confusion, otherwise no one will want to access their site.
If a duplicate domain is found, the user will be able to notify the organizing user who has made the wrong registration, as well as the relay owner in case he accepts the NIP-53, this can also be done automatically.