NIP-05 Verification via Namecoin (.bit) — Now Upstream PR

The narrowest possible upstream slice of the Namecoin-Track NIPs is now open as nostr-protocol/nips#2349:

NIP-05 verification via Namecoin (.bit)

This is one document, one feature, one PR — by explicit request of the RFC issue at #2330 ("one NIP per PR, please, starting with the deepest-deployment one"). The companion drafts for relay discovery, TLSA pinning, and service attestations are intentionally not included; if this one lands, they follow as separate PRs.

For background on the full track (N0–N3 plus draft N4), see the prior long-form note: Namecoin-Track NIPs: Anchoring Nostr Identity, Relays, TLS, and Reputation in a Blockchain.

---

What the PR proposes

A NIP that specifies how clients verify, and publishers publish, a NIP-05 identifier whose right-hand side is anchored in Namecoin rather than DNS + HTTPS. Strict complement to NIP-05; both can coexist on the same identity.

[email protected]       →  d/example,    nostr.names.alice
example.bit             →  d/example,    nostr.names._
[email protected]           →  d/example,    nostr.names._
d/example               →  d/example,    nostr.names._
id/alice                →  id/alice,     nostr.names._
[email protected] →  d/example, walk map.relay, nostr.names.alice

• No new event kinds. Same kind:0 nip05 field as classic NIP-05.
• No new tags.
• No changes to existing NIPs.
• No new top-level Namecoin record keys. Everything Nostr-specific lives under a new nostr item inside the existing ifa-0001 Domain Name Object; ifa-0001's suppression rules require existing consumers to ignore unknown items, so there is no upgrade hazard for the Namecoin ecosystem either.

The N0 ("Namecoin record container") draft has been folded into this document as a §"Namecoin record container" section — a standalone container NIP isn't useful without a consuming NIP, and the maintainers didn't ask for one.

Why this is the right one to upstream first

Eight wire-compatible reference implementations across six platforms ship this NIP against the live Namecoin chain, with byte-for-byte agreement on the same on-chain records:

Platform	Implementation	Status
Android · iOS · Desktop (Kotlin/KMP)	vitorpamplona/amethyst#1734 + follow-ups	merged
iOS (Swift)	nostur-com/nostur-ios-public#60	open
TypeScript / Node (isomorphic)	nbd-wtf/nostr-tools#533	open
Flutter / Dart (nostr on pub.dev)	ethicnology/dart-nostr#44	merged
Web (browser-resident wss:// ElectrumX)	CodyTseng/jumble#774	open
Web	hzrd149/nostrudel#352	open
strfry NIP-05 sidecar (Rust + Node)	mstrofnone/strfry-nip05-namecoin	shipped
Go (drop-in for nostrlib)	mstrofnone/nostrlib-nip05-namecoin, per fiatjaf/nak#123	shipped

Live reference deployment at testls.bit / relay.testls.bit is exercised by the test suites of every implementation above.

What's out of scope (and tracked separately)

• Relay discovery / subdomains / Tor routing via Namecoin — companion draft, see the track note.
• TLSA pinning for .bit relay WebSockets (RFC 6698) — companion draft, see the track note.
• Service attestations with optional Namecoin-anchored identity binding — companion draft, currently draft-only, looking for client implementers.

Happy to open separate PRs for each of those after this one lands, if maintainers want them upstreamed.

Where to comment

• Code-level review, normative wording, numbering: GitHub PR #2349 — that thread is the canonical one.
• Shape-of-API or "do you really need this" feedback on Nostr: reply to this note, or send signed comments (NIP-22) referencing it.

Comments here are welcome and will be folded back into the PR discussion. Please route normative review at GitHub — keeps the spec history coherent for future readers.

— mstrofnone