• A Pure Nostr-Based Naming / DNS-Like System
  • 1. Core Design Principles
  • 2. Mapping Traditional DNS Concepts to Nostr
  • 3. Root Keys (Replacing Root Servers)
  • 4. Namespaces (TLD-Like Delegation)
    • Delegation Event (Example)
  • 5. Zone Authority (Managing a Namespace)
    • IP Record Event
  • 6. Name Resolution Flow
  • 7. Relays Are Not DNS Servers
  • 8. Caching, TTL, and Revocation
    • Caching
    • Updates
    • Revocation Event
  • 9. Trust Model (Critical Difference)
  • 10. Threat Model & Mitigations
    • Typosquatting
    • Namespace Hijacking
    • Spam
  • 11. Philosophical Difference
  • 12. Practical Roadmap
  • 13. Possible Project Names

I believe that without breaking away from the current structure, there’s no way to escape the cage that the internet has trapped us in. For example, an immeasurable amount of computing power is being wasted simply because big corporations decided to hijack the internet through regulatory mechanisms. The mandatory rotation of IPv6 is one example; the closed and authoritarian structure of DNS is another.

I’m not talking about anonymity here. I don’t think complete anonymity is possible. I believe that individual people, at certain times, can remain anonymous and have that right. But in the realm of services and corporations, it’s practically impossible technically. I’m referring to sovereignty.

Thus, I think DNS is the key service for achieving sovereignty. A DNS that can create a parallel internet—one resistant to censorship, sovereign, and capable of restoring what the internet once was, before all this mess caused by bots and now by AI.

Below is a small sketch of what this service could be;

§A Pure Nostr-Based Naming / DNS-Like System

§1. Core Design Principles

The system is built based on the following assumptions:

• ❌ No blockchain
• ❌ No traditional DNS
• ❌ No ICANN, TLD authorities, or global registrars
• ✅ Only Nostr primitives: keys, events, signatures, relays
• ✅ Distributed, censorship-resistant, and cryptographically verifiable
• ✅ Explicit trust, not implicit authority

This is not a replacement for the global Internet DNS, but a foundational name-resolution layer for Nostr-native networks and services.

§2. Mapping Traditional DNS Concepts to Nostr

Key distinction:

Authority comes from keys, not institutions.

§3. Root Keys (Replacing Root Servers)

Instead of root servers, clients embed a small, well-known set of root public keys:

root_keys = [
  npub1rootA...,
  npub1rootB...,
  npub1rootC...
]

Characteristics:

• Hardcoded in resolvers
• Changed extremely rarely
• Managed via social consensus or multisig governance

This is directly analogous to DNS root hints, but cryptographically enforced.

§4. Namespaces (TLD-Like Delegation)

Root keys delegate namespaces to other keys.

§Delegation Event (Example)

{
  "kind": 8000,
  "pubkey": "root_pubkey",
  "content": "",
  "tags": [
    ["ns", "br"],
    ["delegate", "npub1zone..."]
  ]
}

Meaning:

.br → controlled by npub1zone...

Namespaces are unlimited and user-defined:

• .nostr
• .local
• .corp
• .mesh
• .home
• .btc

§5. Zone Authority (Managing a Namespace)

The delegated key is the sole authority for all names within its namespace.

Examples:

example.br
api.example.br
_internal.example.br

§IP Record Event

{
  "kind": 8001,
  "pubkey": "zone_pubkey",
  "content": "",
  "tags": [
    ["name", "api.example.br"],
    ["A", "203.0.113.10"],
    ["AAAA", "2001:db8::1"],
    ["ttl", "300"]
  ]
}

Properties:

• Fully signed
• Relay-replicated
• Append-only (updates are new events)

§6. Name Resolution Flow

Resolving api.example.br:

1. Client loads trusted root_pubkeys

2. Queries relays for kind=8000 events

3. Finds delegation for .br

4. Extracts zone_pubkey

5. Queries kind=8001 events from that key

6. Verifies:

   • Signature validity
   • Delegation chain

7. Returns IP address

Relays are never trusted — only signatures matter.

§7. Relays Are Not DNS Servers

Relays function as:

• Dumb data replicators
• Cacheable
• Replaceable
• Untrusted

Clients may:

• Use public relays
• Run local relays
• Resolve names offline using cache

This architecture is more resilient than traditional DNS.

§8. Caching, TTL, and Revocation

§Caching

• TTL is a hint, not a rule
• Clients choose enforcement policy

§Updates

• Latest valid event wins (by timestamp)

§Revocation Event

{
  "kind": 8002,
  "pubkey": "zone_pubkey",
  "tags": [
    ["revoke", "api.example.br"]
  ]
}

§9. Trust Model (Critical Difference)

This system is explicitly non-universal.

Each client chooses:

• Which root keys to trust
• Which namespaces to accept
• Which relays to query

This is Web of Trust, not centralized authority.

§10. Threat Model & Mitigations

§Typosquatting

• Public key display
• Local key pinning
• Certificate-like UX warnings

§Namespace Hijacking

• Multiple root keys
• Social governance
• Transparent delegation history

§Spam

• Dedicated event kinds
• Pubkey filtering
• Specialized Nostr-DNS relays

§11. Philosophical Difference

Traditional DNS:

“Authority flows from ICANN.”

Nostr-based naming:

“Authority flows from signatures — if we trust the key.”

§12. Practical Roadmap

1. Define a NIP (e.g., NIP-NDNS)

2. Implement:

   • CLI resolver
   • Specialized relay

3. Create:

   • Local resolver daemon (127.0.0.1)

4. Initial use cases:

   • Private infrastructure
   • Homelabs
   • IoT
   • Mesh networks

5. UX refinement

§13. Possible Project Names

• NDNS
• KeyNS
• SigName
• Rootless
• PubResolve

Although this is interesting and has the potential to create a parallel internet not dependent on regulation, I believe that anonymity is still impossible, but censorship is mitigated.

1. Anonymity: it’s fundamentally limited

A Nostr-based naming system cannot provide strong anonymity by itself. In fact, it makes certain linkages stronger.

Why anonymity is hard (or impossible) here

Persistent cryptographic identity

Names → pubkeys → signed events

Persistence is required for authority

Persistence destroys anonymity by definition

Public resolution data

Name → IP mappings are public

IPs imply geography, hosting providers, ASNs

Relay-level metadata

Even with encrypted content:

Event timing

Publish frequency

Relay selection

All leak patterns

Authority requires accountability

If we can update a name, we must be identifiable as the same actor over time

👉 This system optimizes for sovereignty, not anonymity.

2. What it does mitigate well: censorship

Here the design shines.

Censorship resistance properties

✔ No single root server ✔ No central registrar ✔ No takedown authority ✔ No revocation without key compromise ✔ Names exist as long as relays store events

To censor a name, an adversary must:

Block all relays you use, or

Convince you to stop trusting a root key, or

Break cryptography

This is qualitatively stronger than DNS + ICANN + registrars.

3. Important distinction: anonymity vs deniability

Even if anonymity is weak, plausible deniability can still exist.

Examples:

Zone keys can be rotated

Authority keys can be delegated to subkeys

Operators can claim:

“That key is autonomous software”

This is not anonymity, but it raises the cost of attribution.

4. Layer separation is critical

Think in layers:

Layer Property Naming (NDNS) Integrity, persistence Transport (TCP/IP) None Overlay (Tor / I2P / mixnets) Anonymity Application UX, policy

👉 Anonymity must live below or above naming, never inside it.

A realistic stack would be:

NDNS (Nostr) → Tor / I2P / VPN → Application protocol

NDNS gives you:

“This name resolves correctly”

Tor gives you:

“I don’t know who is asking or answering”

5. Why this tradeoff is unavoidable

This isn’t a flaw of Nostr — it’s a fundamental tradeoff:

Naming systems require stable authority. Anonymity requires unstable identity.

You can’t have both at the same layer.

DNS, ENS, Handshake, Tor Onion Names — all obey this rule.

6. What kind of “parallel internet” this really creates

Not an anonymous darknet.

Instead:

A sovereign internet

A non-regulated naming layer

A self-certifying address space

A place where:

“If you know the key, you know the truth.”

This is closer to:

Early Internet + PGP

Usenet with crypto

Meshnets with signed routing

7. Final synthesis

“A Nostr-based naming system cannot guarantee anonymity, but it significantly reduces censorship by removing institutional choke points.”

That’s not a weakness — that’s clarity of purpose.

Let’s imagine such a service acquiring a network effect. I think we even have the possibility of replacing .com with .nostr. Bifurcating the resolution.

1. The key insight: a bifurcated resolver changes a lot of things

The idea of a client that first tries the traditional internet and, on failure, switches to the Nostr network (or the reverse) is the real adoption trigger.

Conceptually:

resolve(name): if dns_resolve(name): return result else if nostr_resolve(name): return result else: return NXDOMAIN

Or even more radically:

example.com → DNS

example.nostr → NDNS

example → client heuristics

📌 This invisible fallback is exactly how new networks win. It’s how:

HTTP evolved into HTTPS

IPv4 partially gave way to IPv6

SMTP adopted STARTTLS

2. Name duplication is not a bug — it’s the rupture

“Two facebook.com, two google.com”

That sounds catastrophic if you think in DNS terms. In this system, it’s a feature, not a flaw.

Why?

Because the meaning of a name stops being:

“Who got here first”

And becomes:

“Which key do you trust?”

So we can have:

facebook.com → key A (corporation) facebook.com → key B (community / fork / mirror / parody)

The client decides — explicitly or by policy.

This breaks:

semantic monopolies

brand authority

institutional capture

📌 It’s the same shock Git introduced to SVN:

forking stops being an exception and becomes the rule.

3. Why big corporations stay out

This touched the critical point: incentives.

For Big Tech, this is a bad deal

They rely on:

crawling

indexing

ads

bots

SEO

control of naming

In this ecosystem:

❌ No central crawler

❌ No global index

❌ Resolution doesn’t leak behavior

❌ Mass scanning is expensive

❌ Bots have no structural advantage

And worse:

They can’t “clean up” the namespace.

There is no:

UDRP

DMCA

ICANN

registrar to pressure

📌 The marginal cost of control trends toward infinity.

4. A real Blue Ocean: why this creates a new market

This system doesn’t compete with today’s web — it sidesteps it.

Who enters first?

Technical communities

Private infrastructure

IoT

Mesh networks

Censored regions

Projects that don’t want to be indexed

The value isn’t visibility, but:

continuity

sovereignty

antifragility

This creates a market where:

spam is expensive

reputation is local

trust is explicit

📌 It’s a blue ocean because the metrics change.

5. The “restart” isn’t utopian — it’s selective

Important nuance: This does not reset the entire internet.

It creates a second plane, similar to:

early Usenet

Tor onion services

private trackers

the early fediverse

But with one crucial difference:

Naming is native, not retrofitted.

6. UX is the real battlefield

None of this works unless the client does the heavy lifting.

Examples of resolver policies:

Prefer NDNS for certain namespaces

Warn when a name exists under multiple keys

Local pinning (“always use this key”)

Trust profiles (“work”, “personal”, “anonymous”)

📌 The user doesn’t choose a domain — they choose trust.

7. Why bots don’t easily ruin it

Bots thrive when:

creation cost is zero

discovery is global

indexing is automatic

Here:

discovery is local

trust is social or manual

resolvers can require proof-of-work

relays enforce policy

Result:

Spam doesn’t scale well.

8. Honest synthesis

What this is describing is:

Not anonymous

Not universal

Not “clean”

Not regulatable

But it is:

resistant to capture

hostile to centralization

economically misaligned with Big Tech

fertile ground for real innovation

“It would be a restart.”

But not a naive reset. It would be a selective restart, for those willing to accept:

freedom with ambiguity sovereignty without guarantees