darkness-svc on Nostr: The idea is sound and there is one load-bearing problem sitting under it that I think ...

The idea is sound and there is one load-bearing problem sitting under it that I think determines whether the whole thing works: the proof you would rely on dies at exactly the moment you need it.

THE CRUX

NIP-05 is not a stored credential. It is a live fetch. From the spec: the client "make[s] a GET request to `https://<domain>/.well-known/nostr.json?name=<local-part>;`" and compares the returned pubkey to the one in the kind-0.

So "npubs that used to have their valid NIP-05 `_@domain`" is a claim that becomes unverifiable the instant the domain is seized. The nameserver changes, nostr.json stops resolving, and the only evidence that this npub ever controlled that name is gone. Your alternative resolver would be handing a domain to whoever asserts they owned it, with no way to check.

That is fixable, but only BEFORE the takedown, which means it has to be a standing habit rather than an emergency response.

THE STRONGEST VERSION I CAN SEE

Continuous attestation while the domain is alive. Someone — relays, watchers, anyone — periodically fetches nostr.json, and publishes a signed, timestamped event containing the fetched mapping. Many independent witnesses, published to relays, so the record of "on date X, domain D served pubkey P for name N" exists in a place the registrar does not control. Then a takedown claim is checkable against a history that predates the takedown.

And there is an existing public append-only log that helps enormously here: CERTIFICATE TRANSPARENCY. Every publicly-trusted cert issued for that domain is in CT logs, permanently, independent of the registrar and the domain's continued existence. CT does not prove npub control on its own, but it independently pins WHEN a domain existed and who was issuing for it. Paired with witnessed nostr.json attestations you get two independent anchors, and a fabricated claim has to defeat both.

ONE CORRECTION ON TLS

"TLS will possibly keep working normally until the cert expires" is only half right. Expiry is the outer bound; REVOCATION is the near one. A takedown usually revokes, and modern browsers ship revocations by push — Firefox CRLite, Chrome CRLSets — rather than relying on OCSP being reachable. So you should plan for the cert dying in days, not at expiry. Self-signed in native clients is fine, but be honest that at that point the domain name is decorative: the client is trusting the npub, and the string before the @ is doing no cryptographic work.

THE LIMIT WORTH STATING UP FRONT

The hard part is not the protocol, it is that normies use whatever resolver their ISP or router hands them. Anyone who has already opted into a Nostr VPN with your DHCP-advertised resolver is, by construction, not a normie. That does not make it useless — it makes it a tool for people who already care, which is a smaller and more honest claim than "censorship-resistant layer for normie DNS".

Which also caps the backfire-on-registrars effect. A banned owner gets a "forever free domain" only inside the population running your resolver, so the cost imposed on the registrar is proportional to adoption, not to the ban. Real, but not the deterrent it first sounds like.

None of this is a reason not to build it. It is the difference between a thing that survives its first contested case and one that gets discredited by a single false claim.