Skip to content
NoDNS.shop

Thesis

A minimal standard for NoDNS should be easy to understand, easy to argue about, and easy to implement.

The goal is a shared baseline for npub names, string names, and record publishing — not a final answer to every future market or governance problem.

Truth

Nostr events are the source of truth.

Consensus

Resolvers and operators agree on the same log.

Convenience

Traditional DNS mirrors the log for normal users.

Protocol walkthrough

How a record becomes DNS

This is the end-to-end flow we should be able to explain without hand-waving: identity, event, validation, payment, DNS, resolution, and renewal.

1. Identity

01

A Nostr keypair is the source of authority. The npub is the public identity; the nsec is the signing power.

For npub-derived names, ownership is cryptographic, not administrative.

2. Choose name class

02

There are two trust models: npub names and string names. They should not be forced into the same rule set.

This is where we decide whether the system is a mirror of identity or a lease market.

3. Publish event

03

The user publishes a NoDNS event with record tags, plus payment/claim/delegation data when needed.

Kind 11111 is the special NoDNS event kind for the current protocol.

4. Validate

04

The bot checks signature, authority, record shape, policy, and payment before it touches DNS.

If anything fails, the event should be visible and explainable, not silently dropped.

5. Apply DNS

05

Valid events become DDNS updates to Knot DNS, which then DNSSEC-signs the result.

This is the convenience layer; the event log is the source of truth.

6. Resolve

06

Resolvers can consume the mirrored DNS view or the event log, depending on their trust model.

The same protocol can support standard DNS users and NoDNS-aware users.

7. Renew

07

Renewal should be deterministic and verifiable, with the event log acting as the proof.

Lease logic matters only for string names; npub names remain cryptographic.

Name model

Should we focus on $npub.tld, or also $npub.subdomain.tld?

This is the biggest conceptual fork. One path makes identity the protocol. The other path makes the operator’s zone part of the product.

For focusing on $npub.tld

  • • Clean cryptographic ownership story.
  • • Simple to explain: the key is the name.
  • • No operator trust needed for the core model.

For also supporting $npub.subdomain.tld

  • • Gives operators a visible deployment zone.
  • • Supports mirror fees and convenience pricing.
  • • Makes nodns.shop a concrete, browser-friendly example.
Suggested position: keep the protocol centered on $npub.tld, but allow subdomain namespaces as opt-in operator deployments.

Decision table

The choices we need to make explicit

This is the room discussion section: state the option, show both sides, then mark the provisional recommendation.

$npub.tld only, or also $npub.subdomain.tld?

Support both, but treat $npub.tld as the fundamental model and subdomain mirroring as an optional convenience layer.

Suggested framing: npub is the protocol; nodns.shop is the first deployment.

Decision

Arguments for

  • +Keeps cryptographic ownership clean and simple.
  • +Lets operators charge only for mirroring, not for ownership.
  • +Makes it easy to explain: npub is the deed; DNS is the mirror.

Arguments against

  • −A subdomain like nodns.shop introduces an operator boundary and extra policy.
  • −If we blur the two, people may think the lease model is the same as cryptographic ownership.
  • −A single namespace story is easier to market than two overlapping ones.

Should Cashu be locked?

Yes — for the first milestone, use locked Cashu with a refund path so bids are public and bidders know the owner must either honor or time out.

Suggested framing: public bid + owner accept + refund if unclaimed; no clawback, but also no permanent lock without a deadline.

Decision

Arguments for

  • +Makes the bid public and clearly tied to the name.
  • +Creates a credible accept-or-refund path for bidders.
  • +Turns the name claim into an explicit owner honor/timeout flow.

Arguments against

  • −Adds some wallet and recovery complexity.
  • −Needs a clear timeout so bids don’t become hostage payments.
  • −Can feel like auction machinery if we overcomplicate the flow.

Should the namespace owner publish pricing or should users bid?

Use a public bid model with a published floor/minimum and owner acceptance; let the market discover value, but keep the rules simple.

Minimal standard: public bid with minimum/accept rules now; consider blind/private bid later if sniping becomes a real issue.

Decision

Arguments for

  • +Bids are visible and easy to discuss publicly.
  • +The owner can still set a minimum / reserve price.
  • +The accept-or-refund flow keeps the model understandable.

Arguments against

  • −Bids can create race dynamics if the domain is highly desirable.
  • −Popular names may need blind bidding later to avoid sniping.
  • −Pricing becomes less deterministic than a posted fee schedule.

Name sniping / blind bids vs public auctions

Keep public bids for v1, but treat blind/private bids as the future answer when we want to hide demand and reduce racing.

Future options: blind bid, registrar-sequenced relay, or a first-come-first-served policy for low-stakes names.

Decision

Arguments for

  • +Blind bids reduce sniping and front-running.
  • +A sequenced/private path can make first-come-first-served practical without revealing the target too early.
  • +Public bids are easy to teach and are enough for the first milestone.

Arguments against

  • −Public bids make racing visible, so popular names may still need a later upgrade.
  • −Blind bids add reveal/verification surface area.
  • −Relay sequencing or registrar-run relays add operational complexity.
Minimal v1 recommendation: Use 11111 as the special NoDNS kind, keep current-state logic in the bot and viewer, and make custom names a public locked bid with a time-bounded refund path; leave 31111 as a future migration only if relay deduplication becomes worth the churn.

Payment semantics

Should Cashu be locked?

For the first milestone, the answer can be yes: a public locked bid with a refund path makes the owner’s choice visible and the bidder’s risk bounded.

Locking Cashu tokens

Use locked Cashu with a refund path in v1 so the bid is public, time-bounded, and clearly honor-or-reclaim.

Recommendation: public locked bid + refund deadline now; later, consider blind bids if public bidding attracts too much sniping.

Decision

Arguments for

  • +Makes the bid public and bound to the name.
  • +Gives bidders a clear refund deadline if the owner does not accept.
  • +Feels like a real market signal without needing a full auction system.

Arguments against

  • −Needs a timeout and reclaim path to avoid hostage payments.
  • −Adds wallet recovery and claim-state complexity.
  • −Can drift into auction machinery if we keep adding rules.

Economics

Should the owner publish pricing, or should people bid?

The first milestone can be a public bid market with a published floor price and owner acceptance, then evolve toward blind bids later if necessary.

Published floor vs public bids

Use a public bid model with a floor/reserve price and owner acceptance for v1.

Decision

Arguments for

  • +Lets the market discover value while still keeping a floor.
  • +The owner can say yes or no without changing the rules.
  • +Public bids are easy to explain in the talk and easy to inspect later.

Arguments against

  • −Public bids can still be raced or sniped for popular names.
  • −A floor price does not fully solve sequencing fairness.
  • −Highly desirable names may still need blind bids later.

Conflict resolution

Public bids now, blind/private bids later?

Popular names are where the system stops being purely technical and starts becoming governance. Public bids are fine for v1; hiding the target is the future tool for sniping and sequencing.

Public bids (v1)

  • • Easy to understand and demo.
  • • Works with a clear refund deadline.
  • • Good enough for the first milestone.

Blind / private bids (future)

  • • Hides demand from squatters and snipers.
  • • Can support sequencing / FCFS without exposing the target.
  • • Could be run through a registrar relay or private sequencing path.
Suggested position: keep public locked bids for v1, then decide later whether blind/private bids or sequenced first-come-first-serve deserve a protocol path.

Future ideas

What should stay out of the first standard?

These are good ideas, but they are not part of the minimal POC. Put them on the board, not in the baseline.

31111 migration as the 'we are live' moment
Blind/private bids to hide demand and reduce sniping
Relay sequencing or registrar-run relay for FCFS fairness
P2PK locking and stronger payment acceptance semantics
Takeover / renewal / namespace expiry mechanics
Multi-operator namespaces and federated trust
Anti-spam alternatives (PoW, burn, escrow variants)

Discussion prompt

What do we standardize now?

Which name classes are mandatory in v1?
Do we need pricing or just acceptance?
Should browser and CLI tools share the same record model?
Which future ideas deserve their own issue instead of landing in the spec?
Open LearnOpen RecordsOpen Register
Bottom line: 11111 is the special NoDNS kind for the current protocol. 31111 is only a future migration if we decide relay dedupe is worth the change.