draft optional author:larrysalibra
On events of kind 0 (set_metadata) one can specify the key "nip69" with a Bitcoin Name System (BNS) name as the value.
Upon seeing that, the client retrieves a GET request on the user's preferred BNS name lookup endpoint or a default one provided by the client, appending the BNS name to the end of the endpoint.
The result should be a JSON document object with a key zonefile that contains the zone file of the name.
The client should parse the the zone file to extract the TXT record with key _._nostr and retrieve the hex formatted public key that is the value. If public key retrieved from the _._nostr TXT record equals the pubkey from the set_metadata event, the client concludes that given public key is can be referenced by the claimed BNS name.
{
"pubkey": "8a9cf8235533cf755be661170eed18e6a2006ec76a88c3fd7d21e6c13bb7b69d",
"kind": 0,
"content": "{\"name\": \"larry\", \"nip69\": \"larry.btc\"}"
...
}and the user has specified the BNS name lookup API endpoint as "https://nostrnames.org/api/names/"
It will make a GET request to https://nostrnames.org/api/names/larry.btc and get back a response that will contain a key zonefile like this:
{
"zonefile": "$ORIGIN larry.btc.\n$TTL 3600\n_redirect\tIN\tURI\t10\t1\t\"https://larrysalibra.com/\"\n\n@\tIN\tA\t161.35.228.61\n\n_._nostr\tIN\tTXT\t\"8a9cf8235533cf755be661170eed18e6a2006ec76a88c3fd7d21e6c13bb7b69d\"\n\n"
}It should parse the string value of the zonefile key using an RFC1035 compliant zonefile parser such as zone-file and retrieve the TXT record with key _._nostr:
_._nostr IN TXT "8a9cf8235533cf755be661170eed18e6a2006ec76a88c3fd7d21e6c13bb7b69d"
If value of the _._nostr TXT record matches the pubkey of the account, the "nip69" association is valid and can be displayed.
A client may implement support for finding users' public keys from BNS names. the flow is the same as above, but reversed: first the client fetches zone file of the BNS name and from there it gets the public key of the user. Finally, it tries to fetch the kind 0 event for that user and check if it has a matching "nip69".
To ensure it is easy for clients to find the kind 0 event of an arbitrary user, one or more TXT records with the key _relay._nostr can be optionally added to a name's zone file with the value set to relays that the user publishes to.
_relay._nostr IN TXT ""wss://relay.example.com"
_relay._nostr IN TXT ""wss://relay2.example.com"
NIP-69 intentionally only supports one user per name and does not use the internet identifier user@domain syntax from NIP-05 that implies domain controls, owns or has some other hierarchical relationship with user. While internet identifiers make sense in federated models where user accounts are given out at the pleasure of the domain this relationship does not exist in Nostr. Nostr users generate and own their own public keys without the help of any third-party. Likewise, Nostr users register and own their own BNS names by signing and broadcasting their own transactions.
For example, if after finding that larry.btc has the public key 8a9...69d, the user clicks a button to follow that profile, the client must keep a primary reference to 8a9...69d, not larry.btc. If, for any reason, the name larry.btc starts returning the public key 1d2...e3f at any time in the future, the client must not replace 8a9...69d in his list of followed profiles for the user (but it should stop displaying larry.btc for that user, as that will have become an invalid "nip69" property). While it would be possible and even potentially desirable to follow NIP-69 names in addition to or instead of public keys, a discussion of this is outside of the scope of this NIP.
Keys must be returned in hex format. Keys in NIP-19 npub format are are only meant to be used for display in client UIs, not in this NIP. Applications making it easier for users to add their public key to a BNS zone file should accept public keys in both hex format and npub format, but must convert npub format keys to hex format prior to storing them in the zone file.
A client can also use this to allow users to search for other users. If a client has a search box or something like that, a user should be able to type a name there and the client would recognize that and perform the the proper lookups to determine if the name exists and contains an associated nostr pubkey and suggest that to the user. Given that the entire set of existing BNS names can be known, it is possible to search as the user types and predict/suggest/autocomplete relevant profiles.
BNS enables any user running the BNS stack (a Bitcoin node, a Stacks node and API endpoint software) to independently, cryptographically, verify the entire state of BNS name system without making requests to any third party services and without depending on any centralized infrastructure. Compared to NIP-05 where domains of all NIP-05 verified accounts a user interacts with receive information about a user's activity, NIP-69 limits this to privacy leak to one endpoint which can be self-hosted. Clients should let users configure their own name lookup endpoint.