From da34c57e99dbf6cadfb3b4176b7c4ff33ac5674c Mon Sep 17 00:00:00 2001 From: dtonon Date: Thu, 29 Aug 2024 16:25:15 +0200 Subject: [PATCH] NIP-05: add identification vs verification note --- 05.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/05.md b/05.md index a1d488df..eeca551a 100644 --- a/05.md +++ b/05.md @@ -58,6 +58,15 @@ A client may implement support for finding users' public keys from _internet ide ## Notes +### Identification, not verification + +The NIP-05 is not intended to _verify_ a user, but only to _identify_ them, for the purpose of facilitating the exchange of a contact or their search. +Exceptions are people who own (e.g., a company) or are connected (e.g., a project) to a well-known domain, who can exploit NIP-05 as an attestation of their relationship with it, and thus to the organization behind it, thereby gaining an element of trust. + +### User discovery implementation suggestion + +A client can use this to allow users to search other profiles. If a client has a search box or something like that, a user may be able to type "bob@example.com" there and the client would recognize that and do the proper queries to obtain a pubkey and suggest that to the user. + ### Clients must always follow public keys, not NIP-05 addresses For example, if after finding that `bob@bob.com` has the public key `abc...def`, the user clicks a button to follow that profile, the client must keep a primary reference to `abc...def`, not `bob@bob.com`. If, for any reason, the address `https://bob.com/.well-known/nostr.json?name=bob` starts returning the public key `1d2...e3f` at any time in the future, the client must not replace `abc...def` in his list of followed profiles for the user (but it should stop displaying "bob@bob.com" for that user, as that will have become an invalid `"nip05"` property). @@ -66,10 +75,6 @@ For example, if after finding that `bob@bob.com` has the public key `abc...def`, Keys must be returned in hex format. Keys in NIP-19 `npub` format are only meant to be used for display in client UIs, not in this NIP. -### User Discovery implementation suggestion - -A client can also use this to allow users to search other profiles. If a client has a search box or something like that, a user may be able to type "bob@example.com" there and the client would recognize that and do the proper queries to obtain a pubkey and suggest that to the user. - ### Showing just the domain as an identifier Clients may treat the identifier `_@domain` as the "root" identifier, and choose to display it as just the ``. For example, if Bob owns `bob.com`, he may not want an identifier like `bob@bob.com` as that is redundant. Instead, Bob can use the identifier `_@bob.com` and expect Nostr clients to show and treat that as just `bob.com` for all purposes.