names.md raw

NIP-XX ======

Free Internet Name Daemon (FIND): Decentralized Name Registry with Trust-Weighted Consensus

draft optional

Abstract

This NIP defines a decentralized name registry protocol for human-readable resource naming with trustless title transfer. The protocol is implemented as an independent service that uses Nostr relays for communication (via ephemeral events) and persistent storage (for name state records). The service uses trust-weighted attestations from registry service operators to achieve Byzantine fault tolerance without requiring centralized coordination or proof-of-work. Consensus is reached through social mechanisms of association and affinity, enabling the network to scale to thousands of participating registry services while maintaining ~51% Byzantine fault tolerance against censorship.

All name registrations last exactly 1 year by network consensus. During the final 30 days before expiration, only the current owner can renew the name (preferential renewal window), preventing last-minute sniping while requiring active maintenance to prevent squatting.

Names follow standard Internet DNS conventions (lowercase, dot-separated hierarchical structure). TLDs are registerable by anyone - there is no ICANN equivalent, meaning valuable TLDs like com, org, net will see intense competition in a first-come-first-served race at network launch.

Name owners can publish DNS-style resource records (A, AAAA, CNAME, MX, TXT, NS, SRV) to define what their names resolve to, enabling use cases from IP address mapping to mail servers to service discovery.

To complete the replacement of traditional DNS and TLS infrastructure, the protocol includes a decentralized certificate system using Let's Encrypt-style challenge-response verification and threshold witnessing, combined with a Noise protocol variant (Nostr Noise) for establishing secure authenticated connections without certificate authorities.

Motivation

Many peer-to-peer applications require human-readable naming systems for locating network resources (analogous to DNS). Traditional approaches either rely on centralized authorities or blockchain-based systems with slow finality times and high resource requirements.

This proposal (Free Internet Name Daemon - FIND) leverages Nostr's existing social graph and relay infrastructure to create a complete naming and security system that replaces both DNS and TLS:

Name Registry Properties:

DNS Replacement:

TLS/CA Replacement:

The protocol is implemented as an independent service (separate from relay software) that communicates via ephemeral Nostr events and stores persistent state as parameterized replaceable events.

Key Innovations:

  1. No Central Naming Authority: Unlike traditional DNS with ICANN controlling TLDs, this protocol allows anyone to register TLDs. Names follow standard DNS conventions (lowercase, dot-separated) ensuring compatibility, but TLDs are first-come-first-served. Subdomain authority is enforced (must own parent domain), creating a hierarchical ownership model without centralized gatekeepers.
  1. Preferential Renewal Window: All names expire after exactly 1 year by network consensus. During the final 30 days before expiration, only the current owner can renew the name, preventing last-minute sniping while ensuring names don't remain claimed indefinitely without active maintenance. After expiration, names become available to anyone on a first-come, first-served basis.
  1. DNS-Compatible Records: Owners publish standard DNS-style resource records (A, AAAA, CNAME, MX, TXT, NS, SRV) as Nostr events, enabling drop-in replacement for traditional DNS in many applications. Per-type limits prevent spam while supporting real-world use cases.
  1. Decentralized Certificates & TLS Replacement: Challenge-response verification (similar to Let's Encrypt) proves name ownership, threshold witnessing (3+ trusted parties) replaces certificate authorities, and a Noise protocol variant using Nostr's secp256k1 primitives provides secure authenticated transport with perfect forward secrecy.

The protocol achieves registration finality in 1-2 minutes, record updates are instant (limited only by relay propagation), and certificate issuance takes minutes, making it suitable for replacing DNS and TLS infrastructure while avoiding the complexity and resource requirements of traditional blockchain consensus.

Specification

Architecture Overview

The name registry protocol is implemented as an independent service that runs separately from Nostr relay software. The service architecture consists of:

Registry Service:

Communication Layer (Ephemeral Events):

Storage Layer (Persistent Events):

Relay Role:

Advantages of Independent Service Architecture:

Event Kinds

This NIP defines the following event kinds:

Expiration Tags:

All event kinds in this protocol support expiration tags (NIP-40) which serve dual purposes:

  1. Protocol Boundary: Defines when an event is no longer valid for protocol operations. Registry services MUST ignore expired events when computing consensus.
  2. Relay Housekeeping: Hints to relays when events can be deleted to reduce storage overhead. Relays MAY (but are not required to) delete expired events.

Expiration ensures that:

Recommended Expiration Periods:

Event KindPurposeNetwork Consensus ExpirationRationale
30100Registration Proposalcreated_at + 300 (5 min)Proposals should be processed quickly; unprocessed proposals are stale
20100Attestationcreated_at + 180 (3 min)Attestations only needed during consensus window
30101Trust Graphcreated_at + 2592000 (30 days)Trust relationships should be actively maintained monthly
30102Name Stateregistered_at + 31536000 (1 year)Name ownership lasts exactly 1 year by network consensus
30103Name RecordsTied to name expirationRecords are valid while name registration is active; expire with name
30104Certificatevalid_until timestampCertificates expire per their validity period (recommended: 90 days)
30105Witness Servicecreated_at + 15552000 (180 days)Witness service info should be updated semi-annually

Name Format and Syntax

Names in this protocol MUST follow standard Internet domain name conventions to ensure compatibility with existing tools and mental models.

Name Format Rules:

  1. Case Normalization: All names MUST be lowercase ASCII only

- Example.Com → normalized to example.com - Names are case-insensitive for registration but stored in lowercase - Uppercase letters in proposals are automatically converted to lowercase

  1. Character Set: Names MUST only contain:

- Lowercase letters: a-z - Digits: 0-9 - Hyphens: - (not at start or end of labels) - Dots: . (label separator)

  1. Label Structure: Names are composed of dot-separated labels

- Each label: 1-63 characters - Total name: maximum 253 characters - Labels cannot start or end with hyphens - Labels cannot be all numeric

  1. Hierarchical Structure: Standard DNS hierarchy applies

- com - top-level domain (TLD) - example.com - second-level domain under com - www.example.com - third-level domain (subdomain) under example.com - api.services.example.com - fourth-level domain

Top-Level Domains (TLDs):

In this protocol, TLDs are just names like any other and can be registered by anyone. There is no reserved set of TLDs (no ICANN equivalent).

// Anyone can register a TLD
{"kind": 30100, "tags": [["d", "com"], ["action", "register"]]}
{"kind": 30100, "tags": [["d", "nostr"], ["action", "register"]]}
{"kind": 30100, "tags": [["d", "bitcoin"], ["action", "register"]]}

TLD Registration Race:

Since TLDs are registerable by anyone, valuable/generic TLDs will likely see intense competition:

The first proposal to achieve consensus wins the TLD. Expect significant competition for short, memorable TLDs in the early network.

Subdomain Authority:

Only the owner of a domain can register its direct subdomains:

This is enforced by the protocol: Registry services MUST verify that the registrant of sub.parent.tld also owns parent.tld.

Examples:

Valid names:

com
example.com
www.example.com
api-v2.services.example.com
my-site.nostr
user123.bitcoin

Invalid names:

Example.Com          # Not lowercase (will be normalized)
exam ple.com         # Contains space
-example.com         # Label starts with hyphen
example-.com         # Label ends with hyphen
exam_ple.com         # Contains underscore
123.456              # All-numeric labels
a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.a.b.c.d.e.f  # > 253 chars

Name Validation:

Registry services and clients MUST validate names against these rules:

  1. Convert to lowercase (normalization)
  2. Check character set (a-z, 0-9, hyphen, dot only)
  3. Validate label lengths (1-63 chars per label)
  4. Validate total length (≤253 chars)
  5. Check hyphen placement (not at label start/end)
  6. Verify label is not all-numeric
  7. For subdomains: Verify parent domain ownership

Invalid names MUST be rejected before attestation.

Registration Proposal (Kind 30100)

A parameterized replaceable event where users propose to register or transfer a name:

{
  "kind": 30100,
  "pubkey": "<claimant_pubkey>",
  "created_at": <unix_timestamp>,
  "tags": [
    ["d", "<name>"],              // name being claimed (e.g., "foo.n")
    ["action", "register"],        // "register" or "transfer"
    ["prev_owner", "<pubkey>"],    // previous owner pubkey (for transfers only)
    ["prev_sig", "<signature>"],   // signature from prev_owner authorizing transfer
    ["expiration", "<unix_timestamp>"]  // proposal expires if not processed
  ],
  "content": "",
  "sig": "<signature>"
}

Field Specifications:

Subdomain Registration:

To register a subdomain (e.g., www.example.com), the proposer MUST own the parent domain (example.com). Registry services validate this during proposal processing:

  1. Proposer owns com TLD
  2. Proposer registers example.com (requires owning com)
  3. Proposer registers www.example.com (requires owning example.com)

This hierarchical ownership ensures that only domain owners can create subdomains, preventing unauthorized subdomain squatting.

Transfer Authorization:

For transfers, the prev_sig MUST be a signature over the following message:

transfer:<name>:<new_owner_pubkey>:<timestamp>

This prevents unauthorized transfers and ensures the current owner explicitly approves the transfer.

Attestation (Kind 20100)

An ephemeral event where registry service operators attest to their acceptance or rejection of a registration proposal. This event is published to Nostr relays for propagation to other registry services:

{
  "kind": 20100,
  "pubkey": "<registry_service_pubkey>",
  "created_at": <unix_timestamp>,
  "tags": [
    ["e", "<proposal_event_id>"],           // the registration proposal being attested
    ["decision", "approve"],                 // "approve", "reject", or "abstain"
    ["weight", "100"],                       // optional stake/confidence weight
    ["reason", "first_valid"],               // optional audit trail
    ["service", "wss://registry.example.com"], // optional: the registry service endpoint
    ["expiration", "<unix_timestamp>"]       // attestation expires after consensus window
  ],
  "content": "",
  "sig": "<signature>"
}

Field Specifications:

- approve: Registry service accepts this registration as valid - reject: Registry service rejects this registration (e.g., conflict detected) - abstain: Registry service acknowledges but doesn't vote

Attestation Window:

Registry services SHOULD publish attestations within 60-120 seconds of receiving a registration proposal. Attestations are posted to Nostr relays as ephemeral events, allowing them to propagate to other registry services via relay gossip. This allows sufficient time for event propagation while maintaining reasonable finality times.

Expiration and Cleanup:

Attestations include an expiration tag that serves two purposes:

  1. Protocol validity: Registry services MUST NOT count expired attestations in consensus calculations
  2. Relay housekeeping: Relays SHOULD delete expired attestations to reduce storage overhead

Once consensus is reached and name state (kind 30102) is published, attestations are no longer needed and relays can safely prune them.

Trust Graph (Kind 30101)

A parameterized replaceable event where registry service operators declare their trust relationships. This event is stored on Nostr relays and used by other registry services to build trust graphs:

{
  "kind": 30101,
  "pubkey": "<registry_service_pubkey>",
  "created_at": <unix_timestamp>,
  "tags": [
    ["d", "trust-graph"],  // identifier for replacement
    ["p", "<trusted_service1_pubkey>", "wss://service1.example.com", "0.9"],
    ["p", "<trusted_service2_pubkey>", "wss://service2.example.com", "0.7"],
    ["p", "<trusted_service3_pubkey>", "wss://service3.example.com", "0.5"],
    ["expiration", "<unix_timestamp>"]  // trust graph expires and requires renewal
  ],
  "content": "",
  "sig": "<signature>"
}

Field Specifications:

- First parameter: Trusted registry service's pubkey - Second parameter: Optional service identifier (URL or other identifier) - Third parameter: Trust score (0.0 to 1.0, where 1.0 = complete trust)

Trust Score Guidelines:

Trust Graph Updates and Renewal:

Registry service operators SHOULD update their trust graphs gradually. Rapid changes to trust relationships MAY be penalized in weighted consensus calculations to prevent manipulation. Trust graphs are stored as parameterized replaceable events on Nostr relays, making them publicly auditable.

Services MUST publish renewed trust graphs before expiration to maintain their trust relationships. An expired trust graph is treated as if the service has no trust relationships, effectively removing it from the consensus network until a new trust graph is published. This ensures that:

  1. Only active, maintained services participate in consensus
  2. Abandoned services automatically drop out of the network
  3. Trust relationships remain current and intentional
  4. Relays can optionally prune very old expired trust graphs

Name State (Kind 30102)

A parameterized replaceable event representing the current ownership state of a name. This event is published by registry services after consensus is reached and stored on Nostr relays:

{
  "kind": 30102,
  "pubkey": "<registry_service_pubkey>",
  "created_at": <unix_timestamp>,
  "tags": [
    ["d", "<name>"],                    // the name
    ["owner", "<current_owner_pubkey>"],
    ["registered_at", "<timestamp>"],
    ["proposal", "<proposal_event_id>"],
    ["attestations", "<count>"],
    ["confidence", "0.87"],             // consensus confidence score
    ["expiration", "<unix_timestamp>"]  // name registration expires and requires renewal
  ],
  "content": "<optional_metadata_json>",
  "sig": "<signature>"
}

Field Specifications:

This event is published by registry services after consensus is reached and stored on Nostr relays as a parameterized replaceable event. This allows clients to quickly query current ownership state from relays without recomputing consensus or running their own registry service.

Name Expiration and Renewal:

All name registrations last exactly 1 year by network consensus. This is not configurable - registry services MUST enforce this standard registration period.

Registration Lifecycle:

T=0:         Name registered (registered_at timestamp)
T=0-335d:    Active registration, owner has exclusive control
T=335-365d:  Preferential renewal window (final 30 days)
T=365d:      Expiration - name becomes available to anyone

Preferential Renewal Window (Days 335-365):

During the final 30 days before expiration (starting at day 335, approximately 11 months), ONLY the current owner can successfully register the name. Registry services MUST reject registration proposals from other pubkeys during this window. This gives owners time to renew while preventing last-minute sniping.

After Expiration:

After the expiration timestamp passes, the name becomes available for registration by anyone. The original owner has no special claim and must compete with other claimants through the standard consensus process.

The expiration mechanism serves multiple purposes:

  1. Anti-squatting: Prevents indefinite holding of unused names
  2. Fair renewal: Owners get 30 days exclusive renewal window
  3. Protocol boundary: Clear definition of when ownership lapses
  4. Relay housekeeping: Relays MAY delete expired name state events

Name Records (Kind 30103)

Once a name is successfully registered, the owner can publish DNS-style resource records to define what the name resolves to. These records are parameterized replaceable events published by the name owner and stored on Nostr relays.

{
  "kind": 30103,
  "pubkey": "<name_owner_pubkey>",
  "created_at": <unix_timestamp>,
  "tags": [
    ["d", "<name>:<record_type>"],     // e.g., "foo.n:A" or "foo.n:AAAA"
    ["name", "<name>"],                 // the registered name
    ["type", "<record_type>"],          // A, AAAA, CNAME, MX, TXT, NS, SRV
    ["value", "<record_value>"],        // IP address, hostname, text, etc.
    ["ttl", "3600"],                    // cache TTL in seconds
    ["priority", "10"],                 // for MX and SRV records (optional)
    ["weight", "50"],                   // for SRV records (optional)
    ["port", "443"]                     // for SRV records (optional)
  ],
  "content": "",
  "sig": "<signature>"
}

Field Specifications: