Mirror/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-13 02:46:24 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge pull request #227 from erikwestra/nip-05-security-proposal

Browse Source 
Nip 05 security proposal
This commit is contained in:
mplorentz 2023-02-09 14:43:06 -05:00 committed by GitHub
commit 6d55463c89
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
05.md
View File

@ -35,7 +35,7 @@ It will make a GET request to `https://example.com/.well-known/nostr.json?name=b
}
````
or with the **optional** `"relays"` attribute:
or with the **optional** `"relays"` and/or `"account_uris"` attributes:
```json
{
@ -44,6 +44,9 @@ or with the **optional** `"relays"` attribute:
},
"relays": {
"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [ "wss://relay.example.com", "wss://relay2.example.com" ]
},
"account_uris": {
"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": "https://bob.com/profile/bob"
}
}
````
@ -52,6 +55,8 @@ If the pubkey matches the one given in `"names"` (as in the example above) that
The optional `"relays"` attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays that user may be found. Web servers which serve `/.well-known/nostr.json` files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available.
The optional `"account_uris"` attribute may contain an object with public keys as properties and URIs as values. When present, this allows clients to direct their users to a URI which provides more information about the account on the server which was used to validate the given public key. Clients should ignore any URIs which don't include the server's `<domain>`.
## Finding users from their NIP-05 identifier
A client may implement support for finding users' public keys from _internet identifiers_, the flow is the same as above, but reversed: first the client fetches the _well-known_ URL and from there it gets the public key of the user, then it tries to fetch the kind `0` event for that user and check if it has a matching `"nip05"`.
@ -66,6 +71,10 @@ 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 are only meant to be used for display in client UIs, not in this NIP.
### Clients should display the name used to verify the public key
While users can choose their own Nostr username, displaying that username beside the "verified" icon and the name of the verifying server alone is an invitation for abuse. A malicious user could verify their public key using one account name, and then display a different account name within Nostr, misleading users into thinking they are someone else. To prevent this, clients should display the user's account name on the verifying server, rather than (or in addition to) their self-selected username within Nostr.
### 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.