<oembed><type>rich</type><version>1.0</version><author_name>codonaft (npub1al…7rg94)</author_name><author_url>https://nostr.ae/npub1alptdev5srcw2hxg03567p4k6xs3lgj7f6545suc0rzp0xw98svse7rg94</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>Thanks. That&#39;s the tricky part and I&#39;d love to hear suggestions on it.&#xA;&#xA;The trust to dns-specialized relays (+clients + nameservers), capable of verifying NIP-05 *before* the takedown, appears to be inevitable.&#xA;&#xA;Briefly, something blockchain-based/like could be a solution, which could be implemented entirely on Nostr: these relays receive the domain owner&#39;s event kind 0, verify nip05 and broadcast a note with verification proof, which refers to the event kind 0. Other dns-specialized relays receive the proof but don&#39;t make it available for requesting until they themselves reverify it. They sign another proof, which refers to the newest existing proof for the same event kind 0 and broadcast that.&#xA;&#xA;The relays would need to reject incoming too new/old events, so in this case, a new relay/nameserver won&#39;t be able to resolve domains that were taken down before the relay was deployed (or, alternatively, the relay could temporarily trust other manually selected dns-specialized relays and load old events from them after deployment).&#xA;&#xA;When there&#39;s no takedown—resolve using normal recursive nameserver.&#xA;&#xA;In case of takedown (detected while resolving using the recursive nameserver):&#xA;- if it&#39;s a new unknown takedown—relay signs the fact of the takedown and broadcasts to others for the similar confirmation process; may temporarily fail to resolve&#xA;- otherwise resolves records from an event signed by domain owner&#39;s npub, who has a corresponding newest nip05 proof with the `created_at &lt; takedown_at` and the newest existing corresponding proof of the takedown; both proofs are with at least N confirmations.&#xA;&#xA;I think that should work normally in case of voluntarily selling the domain as well (if the new owner broadcasts their event kind 0 for verification after acquisition).&#xA;&#xA;The first takedown of the last corresponding proven nip05-verified npub is a real takedown; other takedowns and nip05 verifications after the takedown are ignored.&#xA;&#xA;I wonder whether I&#39;m missing some important case or something could be simplified.</html></oembed>