feat: Namecoin (.bit) NIP-05 resolution

[mstrofnone]

Summary

Adds optional Namecoin .bit NIP-05 verification to nos.

Any identifier ending in .bit (or starting with d/ / id/) is
routed through a small ElectrumX client and matched against the
Namecoin chain's published nostr field instead of the standard
/.well-known/nostr.json HTTPS lookup. Everything else falls through
to the existing HTTP path unchanged.

Implementation

Direct port of the resolver from
nostur-com/nostur-ios-public#60. Same wire
format, same ElectrumXClient surface, same suffix-branch hook in the
verify call site.

One small correctness fix over the Nostur template: the name-script
parser now accepts OP_NAME_FIRSTUPDATE (0x52) in addition to
OP_NAME_UPDATE (0x53). Names that are still in their first-update
window otherwise resolve to nil even when the chain has the data — a
known bug in several other ports across the ecosystem. The chosen test
fixture (mstrofnone.bit) exercises exactly that code path.

Why

.bit gives Nostr users a DNS-free, censorship-resistant identity
layer. NIP-05 verification is the natural entry point — same UX
(name@example.bit), no UI changes, falls back gracefully if any of
the default ElectrumX servers are unreachable.

Scope

• One ElectrumXClient (Network.framework TLS + TOFU cert pinning)
• One name-value parser (d/ and id/ namespaces; both the extended
  nostr.names tree and the short "nostr":"hex" / nostr.pubkey
  forms)
• One NamecoinService actor singleton + in-memory cache
  (1h TTL, 500 entries)
• One hook in NamesAPI.verify() — a single if branch in front of
  the existing HTTP flow
• No UI changes (the existing NIP05View covers it; verified .bit
  identifiers render exactly like verified DNS ones)
• 17 unit tests in NamecoinResolverTests

Wire format

ifa-0001 + ElectrumX scripthash.get_history + transaction.get +
Namecoin name-script parsing. Same as
Amethyst (Kotlin, merged),
dart-nostr (merged),
Nostur (Swift, in review),
and in-review across the JS ecosystem. See the
N1 NIP draft.

Try it

• mstrofnone.bit resolves to npub1gvv9ahktvavf9qjtrgm62le7gplmmchd5usp5wpfhr85hf79kncqj8xchs
• _@mstrofnone.bit is equivalent
• Anything that doesn't end in .bit falls through to the existing
  HTTP NIP-05 path

The wire path was live-verified against the public Namecoin
ElectrumX network (nmc2.bitcoins.sk:57002) before opening this PR.

Footprint

1421 lines added across 9 files (1106 lines of resolver + 315 lines of
tests; 13 lines of integration in NamesAPI.swift; one Xcode project
entry per new file).

A full Xcode build needs signing on the reviewer's side; static type
check passes against iphonesimulator SDK. CI should be a clean run.

Update (2026-05-24): ifa-0001 import-chain support

Follow-up commit 11609401 adds full support for the ifa-0001 §"import"
chain so that real-world .bit records like testls.bit resolve
end-to-end.

Why this is needed

Namecoin imposes a 520-byte limit on each name's value. Apex records
that carry a nostr.names directory (and any other shared blocks)
quickly run up against that limit, so the ifa-0001
spec
defines an import key that lets the apex delegate shared sections
into a sibling name — conventionally dd/<name>. The canonical demo
target testls.bit uses this pattern: d/testls carries only
{"import":"dd/testls", ...} and the nostr.names block lives at
dd/testls. Without import handling the resolver sees no nostr
field at the apex and returns nil — the lookup silently fails.

What the new resolver does

NamecoinImportResolver.expandImports is called once between the
JSON parse and the existing nostr field extraction in both
performLookup and performLookupDetailed. Records without an
import key short-circuit immediately and pay zero extra
ElectrumX I/O.

For records that do declare an import, the resolver implements the
full ifa-0001 §"import" semantics:

• All four value shapes the spec defines: canonical
  [["d/foo","sel"], ...] plus the three shorthand forms
  ("d/foo", ["d/foo"], ["d/foo","sel"]) that show up in
  real-world records.
• Importer-wins merge. Keys in the importing object replace the
  imported value; a JSON null in the importer suppresses the
  imported key (semantic suppression per spec).
• Recursion depth 4 (the spec minimum) with a visited
  (name, selector) set so cycles like d/a → d/b → d/a terminate.
• Subdomain selector resolved against the imported value's map
  tree using exact-label > * wildcard > "" default at each level,
  walked DNS-right-to-left.
• Lenient I/O. Lookup returns nil, malformed JSON, malformed
  import value → treated as {}. The importer's own fields still
  apply, so transient ElectrumX hiccups can't nuke an otherwise
  resolvable record.
• The merged import key is stripped before the extractor sees the
  object.

Tests

NosTests/Service/NamecoinImportTests.swift adds 20 hermetic tests
(no network, in-memory ElectrumX double):

• 16 pure unit tests on the resolver: passthrough on non-import
  records, each shorthand form, importer-wins, null suppression,
  4-level recursion, depth-budget truncation, lenient lookup failure,
  malformed JSON, malformed import value, cycle protection,
  multi-label selector descent, wildcard fallback, etc.
• 4 integration tests through NamecoinResolver covering the
  testls.bit pattern, resolveDetailed returning .success and
  .noNostrField across an import, and a regression guard asserting
  that non-import records issue exactly one ElectrumX query.

Files

• Nos/Service/Namecoin/NamecoinImportResolver.swift (new)
• Nos/Service/Namecoin/NamecoinResolver.swift (wiring)
• NosTests/Service/NamecoinImportTests.swift (new)
• Nos.xcodeproj/project.pbxproj (target membership for the two new
  files)

The diff is scoped to the import path. Existing public APIs,
extractor behaviour, and caching are unchanged.

[github-actions]

CLA Assistant Lite bot: Thank you for your submission -- we really appreciate it! We'd love it if you'd sign our Contributor License Agreement so we can accept your contribution. You can sign the CLA by copying the text below, pasting it in the Add a comment text field at the bottom of this pull request, and clicking the Comment button to post it.

---

I have read the CLA Document and I hereby sign the CLA

---

mstrofnone seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You can retrigger this bot by commenting recheck in this Pull Request}