NIP-53
======

Nostr-based domain registration system
--------------------------------------

`draft` `optional` `author:leandro21b`

## Name:

Nostr Domain System (NDS)

## Description:

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

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
{
    "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.