nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-30 00:41:20 +00:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
This reverts commit 6d55463c89, and d87763781d reversing
changes made to a1a090160b.
This commit is contained in:
Matthew Lorentz 2023-02-09 16:59:50 -05:00
parent d87763781d
commit 9d0b59d381
1 changed files with 1 additions and 10 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"` and/or `"account_paths"` attributes:
or with the **optional** `"relays"` attribute:
```json
{
@ -44,9 +44,6 @@ or with the **optional** `"relays"` and/or `"account_paths"` attributes:
},
"relays": {
"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [ "wss://relay.example.com", "wss://relay2.example.com" ]
},
"account_paths": {
"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": "/profile/bob"
}
}
````
@ -55,8 +52,6 @@ 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_paths"` 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 that provides more information about the account on the same NIP-05 server -- for example, if the address is `"bob@example.com"` and the account_path for Bob's public key is `"/profile/bob"` the client may have a link to `https://example.com/profile/bob` at Bob's NIP-05 address.
## 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"`.
@ -71,10 +66,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 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.