📜 Overview

🌐 Why DNN?

Problems 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 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

1. 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 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 Model

4. Sync Mechanism

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

🔗 How DNN Works

Name 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 Resolution

• 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

Example

alice.n50.5
alice.b1000050.5

Position = 1 (or omitted)

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

🔣 Human-Readable & Human-Memorable Encoding

How 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 Results

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 Use

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

🚀 Use Cases

1. Decentralized Web Browsing

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

2. nostr Identity

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

3. 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 Anywhere

• 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.

5. 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 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