📜 Overview📜 Overview

The Decentralized Naming Network (DNN) is a protocol and network of nodes that enables users to register, resolve, and manage human-readable names in a fully decentralized manner. DNN uses the NIP-DN standard (Decentralized Names) for name registration and resolution, anchoring all records to the Bitcoin blockchain for security and spam resistance.

🌐 Why DNN?🌐 Why DNN?

Problems with Traditional Naming SystemsProblems with Traditional Naming Systems

• Centralization: ICANN/DNS is controlled by centralized entities.
• Fragility: NIP-05 relies on domain ownership, which can be lost or revoked.
• Complexity: nostr npubs are long and not user-friendly.

DNN SolutionsDNN Solutions

• Decentralized: No single point of control or failure.
• Spam-Resistant: Requires a Bitcoin self-transfer for name registration.
• Interoperable: Works with nostr clients, browsers, email, and more as they support the protocol.
• Fast & Scalable: Syncs with Bitcoin’s block tempo (~10 minutes).

🏗️ Architecture🏗️ Architecture

1. DNN Nodes1. DNN Nodes

• Each DNN node is a nostr relay, storing and syncing blocks of valid kind:60600 (anchor) events.
• Nodes connect and sync using peer-to-peer methods similar to Bitcoin nodes.
• Each DNN block corresponds to a Bitcoin block, ensuring global consensus.

2. Block Structure2. Block Structure

• Each DNN block contains multiple valid kind:60600 events, anchored to a specific Bitcoin block.
• Blocks are continuously added, in sync with Bitcoin (~10 minutes per block).

3. Data Model3. Data Model

NIP-DN defines the event types and rules for name registration and resolution.

4. Sync Mechanism4. Sync Mechanism

• Every ~10 minutes, nodes perform a sync-check to ensure all nodes have the same data.

🔗 How DNN Works🔗 How DNN Works

Name RegistrationName Registration

1. Publish a kind:61600 event with your desired name.
2. Publish a kind:62600 event with connection data.
3. Publish a kind:63600 event with metadata.
4. Publish a kind:60600 event, referencing the above and including a Bitcoin self-transfer as proof.

Name ResolutionName Resolution

A DNN-aware browser or client resolves names using either DNN block numbers or Bitcoin block numbers, with support for shorthand notation:

• DNN Block Format:
  name.n{DNN_block}[.{position}]
  • If the position is 1 or omitted, it refers to the first entry in the block.
  • Example: alice.n50.1 = alice.n50
• Bitcoin Block Format:
  name.b{bitcoin_block}[.{position}]
  • If the position is 1 or omitted, it refers to the first entry in the block.
  • Example: alice.b1000050.1 = alice.b1000050
• Position:
  • The {position} index in name.n{DNN_block}[.{position}] and name.b{bitcoin_block}[.{position}] is the same for both formats. It is determined by the first transaction in the block that satisfies all of the following criteria:
    1. Sender = Receiver (a self‑transfer).
    2. Exactly one address appears in the transaction’s inputs and outputs.
    3. Fee rate ≥ 5 vBytes.
• Shorthand Notation:
  For easier readability, you can use:
  • h = hundred
  • k = thousand
  • m = million
  • b = billion
  • t = trillion
  • qd = quadrillion
  • qt = quintillion
  • sp = Septillion
  • o = Octillion
  
  
  Examples:
  • alice.n500.1 = alice.n500 = alice.n5h.1 = alice.n5h
  • alice.b1000500.1 = alice.b1000500 = alice.b1m5h.1 = alice.b1m5h

ExampleExample

For a record anchored at DNN block 50 (which is anchored to Bitcoin block 1 000 050) and that is the 5th qualifying transaction in that block:

alice.n50.5
alice.b1000050.5

All two notations resolve to the same record because the {position}=5 refers to the same qualifying transaction in both the DNN and Bitcoin representations.

Incorrect mapping such as alice.n50.5 ↔ alice.b1000050.25 is not valid; the position numbers must match.

If a client queries a position that does not exist (e.g., alice.b1000050.10 when the block only has three qualifying transactions), it should return an error like “record not found”.

Position = 1 (or omitted)Position = 1 (or omitted)

alice.n50.1 = alice.n50 = alice.n5h.1 = alice.n5h
alice.b1000050.1 = alice.b1000050 = alice.b1m50.1 = alice.b1m50

These eight notations all resolve to the same first valid record in DNN block 50 / Bitcoin block 1 000 050.

🔣 Human-Readable & Human-Memorable Encoding🔣 Human-Readable & Human-Memorable Encoding

To improve human readability and memorability and make referencing DNN names easier, DNN supports an extra encoded format that compresses the block number and transaction position into a compact alphanumeric string.

How It WorksHow It Works

1. Prefixes:
   • The encoding starts with a 3-letter prefix, derived from permutations of the alphabet (e.g., abc, zyx).
   • This prefix indexes batches of Bitcoin blocks grouped by a fixed batch size (default 5 blocks per batch).
   • When the number of batches exceeds the number of prefixes (15,600), a numeric cycle count is appended to the prefix to extend capacity (e.g., abc1, zyx3).
2. Suffixes:
   • The suffix encodes the offset within a batch, which combines the block position within the batch and the transaction position in that block.
   • This offset is encoded dynamically into words from the BIP-39 wordlist, producing human-readable strings like abandon, zoo, or concatenations separated by dashes (e.g., abandon-zoo).
3. Encoding Steps:
   • Compute the batch index from the block number: batch_index = block_number // blocks_per_batch.
   • Determine the prefix by selecting the batch index modulo total prefixes and appending the cycle count if needed.
   • Calculate the offset within the batch combining block offset and transaction position.
   • Encode the offset into BIP-39 words.
   • Join prefix and suffix with a hyphen.

Example Encoding ResultsExample Encoding Results

Using the default batch size of 5 blocks and a small sample BIP-39 wordlist (2 words) for demonstration, here are some example inputs and their encoded outputs:

Note: The above outputs are based on the sample BIP-39 list of two words ("abandon", "zoo") for demonstration. The full BIP-39 list (2048 words) will yield more compact and meaningful suffixes.

An actual example would be 100.1 => abw-ability, 956453.45546 => gvl12-rocket-tumble, or 10353053.35656 => tal132-road-baby

How to UseHow to Use

Instead of referring to alice.n50.5 or alice.b1000050.5, you can use the encoded notation like:

alice.agd-abandon
alice.ytj-abandon-zoo

This shorthand improves readability while maintaining uniqueness and reversibility back to block number and transaction position.

🚀 Use Cases🚀 Use Cases

1. Decentralized Web Browsing1. Decentralized Web Browsing

• Replace https://example.com with name.n50.3, n50.3, or nabmabout in the address bar.

2. nostr Identity2. nostr Identity

• Use name.n50.3, n50.3, or nabmabout as your nostr handle.

3. Email & Messaging3. Email & Messaging

• Send/receive email using n50.3/name@n50.3, or nabmabout/name@nabmabout where you can potentially have as many emails as you want (yet to be figured out)

4. Receive Money from Anywhere4. Receive Money from Anywhere

DNN names can be linked to a wide range of payment methods, making it easy for anyone to send you money—whether via cryptocurrency, lightning networks, or even traditional payment systems.

• Bitcoin & Lightning: Accept Bitcoin on-chain (including Silent Payments) or via the Lightning Network for instant, low-cost transactions.
• Other Cryptocurrencies: Link Ethereum, Litecoin, or any other crypto address to your DNN name.
• Traditional Payments: If supported, you can even associate PayPal, bank accounts, or other payment methods with your DNN name, allowing for flexible and user-friendly transactions.

This makes DNN names a universal identifier for receiving payments, simplifying the process for both senders and receivers.

5. Relay Discovery5. Relay Discovery

• Add a few relays and have it be discovered by anyone trying to interact with you. When a client resolves alice.n50.3, it instantly receives the relay URLs and can connect without any separate outbox lookup or manual configuration.

6. Proxy or Delegated npub Posting6. Proxy or Delegated npub Posting

• Users can delegate posting authority to a proxy npub that can publish events (e.g., kind:1 metadata updates) on their behalf.
• Events posted by the proxy npub are associated with the user's DNN name, enabling seamless identity management.
• This keeps the user's main npub private and secure while allowing flexible management.
• If the proxy npub is compromised or needs to be replaced, users can simply swap it out without changing their main identity or DNN name.
• This mechanism enhances security and convenience by separating identity from posting keys.

📋 Specification📋 Specification

For the full technical specification, see NIP-DN.