Namecoin-Track NIPs: Anchoring Nostr Identity, Relays, TLS, and Reputation in a Blockchain

A small, separable set of Nostr Implementation Possibilities that move pieces of the existing Nostr stack — NIP-05 verification, relay discovery, Tor routing, TLS pinning, and (optionally) service-attestation reputation — out of DNS + Web PKI and into the Namecoin blockchain. Wire-compatible with Nostr today; additive, not breaking.

Drafts: github.com/mstrofnone/nips · License: CC0-1.0.

---

Why anchor any of this in Namecoin?

Two assumptions sit underneath classic NIP-05 and classic NIP-65:

1. The DNS root is honest and your registrar won't quietly reassign your name.
2. Public Certificate Authorities won't mint a cert for your domain to someone else.

Both fail in practice. Registrars get coerced. CAs get compromised. The fix isn't to abandon DNS — it's to give people who care a second, censorship-resistant path that interoperates with the first.

Namecoin's d/<name> records (and the parallel id/<name> identity records) are 520-byte UTF-8 JSON blobs published on a Bitcoin-merge-mined chain(approx. 60% of current bitcoin hashrate). The chain is the registrar; there is no other one. There is no certificate authority — TLSA records pin keys directly. That is the entire idea.

The four NIPs

Each NIP in the track is independently implementable. A client can ship one and remain fully interoperable with everything else.

N0 — Namecoin record container for Nostr

A single new item type, nostr, that lives inside an ifa-0001 Domain Name Object. Defines nostr.names (hex pubkeys keyed by local-part), shared import / map walking semantics, encoding constraints, security rules. Foundation for the other three. Zero new top-level Namecoin record keys — everything Nostr-specific lives under one item.

N1 — NIP-05 verification via Namecoin (.bit / d/ / id/)

How a client verifies, and a publisher publishes, a NIP-05 identifier whose right-hand side is anchored in Namecoin instead of DNS+HTTPS.

[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

Covers ElectrumX TCP+TLS and browser WebSocket transports, caching, expiry, race-condition handling, Tor integration, browser portability. Strict complement to NIP-05 — never replaces it.

N2 — Relay discovery, subdomains, and Tor routing via Namecoin

How a client opens wss://example.bit/ (or wss://relay.example.bit/) by resolving the host through Namecoin and routing it to a real WebSocket endpoint, optionally via a .onion or _tor.txt anchor. Reuses ifa-0001 map, import, tor and ifa-0002 tor items verbatim. Includes the load-bearing security property that a parent record's TLS material does not inherit to subdomain relays.

N3 — TLSA pinning for .bit Nostr relay WebSockets (RFC 6698)

How a client pins the resolved TLS handshake against on-chain RFC 6698 TLSA records published in the same Namecoin name. Makes a public-CA MITM ineffective against .bit relay traffic even with a valid clearnet certificate for the resolved host. No silent PKIX fallback once tls is published. Covers the encaya/ncgencert AIA-stapled-SPKI edge case.

N4 — Service attestations with optional Namecoin-anchored identity binding

Two new event kinds (38383 service attestation, 38384 attestation set) for signed, structured, replaceable attestations that one pubkey performed a service or task for another. Optional nmc tag binds the attested pubkey to a Namecoin name at a specific block height — a verifier re-runs the N1 lookup at that height and confirms the binding was active when the work was completed. Stops backdating reputation onto a name that didn't hold the key at the time. Re-uses N0's container and N1's lookup primitive; introduces no new top-level Namecoin record keys. Currently draft-only — looking for client implementers.

Reference implementations

A short tour of working code for a variety of clients:

• Amethyst (Android · iOS · Desktop, Kotlin/KMP) — NIP-05 over Namecoin landed in #1734; race-condition fixes #1771; custom ElectrumX servers #1786; Samsung One UI 7 TLS pinning #1937; .bit relay + TLSA + Tor stack #2595; import resolution #2612 · #2707; iOS port #2199; Desktop port #1914.
• Nostur (iOS, Swift) — PR #60.
• nostr-tools (TypeScript, isomorphic) — PR #533.
• Jumble (web client, browser-resident wss:// ElectrumX transport) — PR #774. The reference for the WebSocket transport in N1.
• noStrudel (web) — PR #352.
• strfry NIP-05 sidecar — github.com/mstrofnone/strfry-nip05-namecoin.
• strfry write-policy plugin — github.com/mstrofnone/strfry-namecoin-policy.
• nak / nostrlib — proposed nip05/namecoin subpackage; shape at github.com/mstrofnone/nostrlib-nip05-namecoin, discussed in nak#123.
• nak-nmc (standalone wrapper) — github.com/mstrofnone/nak-nmc.
• nmcLightningService (Node, end-to-end publishing pipeline) — github.com/mstrofnone/nmcLightningService.

A live reference deployment sits at relay.testls.bit / testls.bit and is exercised by the test suites of every implementation listed.

API-shape guidance for libraries

Crystallised out of the nak#123 discussion:

• The lookup function MUST NOT bake in a specific server list — accept it (or a function returning it) as a parameter, with per-call overrides.
• The lookup function MUST NOT bake in a specific transport — WebSocket and TCP+TLS SHOULD be selectable; browser-only builds ship just WebSocket.
• The library API SHOULD mirror existing NIP-05 entry points (QueryIdentifier / queryProfile) so callers don't need a separate codepath for .bit.
• Pinned TLS material belongs in an optional plug-in, not core. Browsers can't use it; not all native clients want it.

On numbering

The repo uses local placeholders N0..N3. N is outside the hex alphabet [0-9A-F], so it can never collide with upstream's hex-extended numbering. If any of these get upstreamed into nostr-protocol/nips, they pick up the next merge-order number and the N* file becomes a redirect.

What's next

We're opening an RFC issue against nostr-protocol/nips to gauge maintainer interest before sending any PR. N1 (NIP-05 over Namecoin) — is the natural first candidate to upstream, on the strength of having merged in Amethyst. The RFC will cover N0–N3 only; N4 stays in-repo until it has client implementations.

N4 in particular is looking for a first client implementer. If you ship a Nostr marketplace, a freelancer board, a peer-recommendation graph, or anything where attestation provenance matters — this is the layer that lets your users carry receipts forward across clients and across pubkey rotations. Talk to me on Nostr.

Feedback on Nostr is welcome and frankly preferred. Reply or send signed comments to the address in the source.

— mstrofnone