• What it does
• How it relates to the Dart precedent
• Live verification
• Where this fits in the track
• Refs

Sixth shipping reference implementation of Namecoin NIP-05 — Flutter/Dart, on a Nostr client.

A PR against haorendashu/nostrmo adds .bit resolution to nostrmo’s existing NIP-05 path. The diff is small and tightly scoped: a self-contained helper under lib/util/namecoin/ plus two two-line branches at the existing call sites.

→ PR: https://github.com/haorendashu/nostrmo/pull/33

§What it does

For an address shaped like alice@something.bit, something.bit, d/<name> or id/<name>, the new helper queries the corresponding Namecoin record over a public ElectrumX server, parses the nostr field of the record’s value JSON, and returns the pubkey (and any published relays) — just like the existing Nip05Validor does for DNS-hosted NIP-05.

Three value shapes are accepted, matching the cross-language reference implementations:

{ "nostr": "<hex pubkey>" }
{ "nostr": { "names": { "alice": "<hex>", "_": "<hex>" }, "relays": { ... } } }
{ "nostr": { "pubkey": "<hex>", "relays": ["wss://...", ...] } }

Records that delegate via the ifa-0001 import item (so the nostr.names map can grow past the 520-byte per-name value cap) are resolved by walking imports up to four levels deep, with cycle detection. Both NAME_UPDATE (OP_3) and NAME_FIRSTUPDATE (OP_2) outputs are decoded, so newly-registered names resolve immediately.

§How it relates to the Dart precedent

The wire format mirrors ethicnology/dart-nostr PR #44, which merged into the upstream nostr package on pub.dev on 2026-05-16 — the canonical Dart implementation of Namecoin NIP-05 (plus NIP-N2 relay resolution and NIP-N3 TLSA pinning).

nostrmo depends on haorendashu/nostr_sdk (a separate Dart SDK, not the pub.dev nostr package), so this PR ships the resolver app-locally rather than as a nostr_sdk change. That keeps the SDK submodule untouched and the change easy to review. If maintainers prefer it lifted into nostr_sdk, a follow-up SDK PR is a one-paragraph job.

§Live verification

Tested against the real Namecoin blockchain via the default ElectrumX endpoint (electrum.nmc.ethicnology.com:50004, Let’s Encrypt cert, no pinning required):

m@testls.bit     → 6cdebccabda1dfa058ab85352a79509b592b2bdfa0370325e28ec1cb4f18667d
testls.bit       → 460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c
mstrofnone.bit   → 43185edecb675892824b1a37a57f3e407fbde2eda7201a3829b8cf4ba7c5b4f0
id/mstrofnone    → 43185edecb675892824b1a37a57f3e407fbde2eda7201a3829b8cf4ba7c5b4f0
doesnotexist.bit → null

valid("m@testls.bit", "6cdebcca…") → true; valid("m@testls.bit", "0000…") → false. Both branches behave the same way the existing Nip05Validor.valid does, so the upstream call sites (MetadataProvider.getNip05Status, login-by-NIP-05) work unmodified once the .bit-suffix branch routes through.

§Where this fits in the track

Sixth client, fifth runtime, no spec drift across any of them.

§Refs

• NIP draft: nostr-protocol/nips#2349 (“NIP-05 verification via Namecoin (.bit)”)
• N0–N5 track home: mstrofnone/nips
• Spec: ifa-0001 Domain Name Object
• Dart wire-format precedent: ethicnology/dart-nostr#44 (merged)

🔐 #namecoin #nip05 #nostrmo #flutter #dart