mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-22 16:35:52 -05:00
Revert "Merge pull request #227 from erikwestra/nip-05-security-proposal"
This reverts commit6d55463c89
, andd87763781d
reversing changes made toa1a090160b
.
This commit is contained in:
parent
d87763781d
commit
9d0b59d381
11
05.md
11
05.md
|
@ -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
|
```json
|
||||||
{
|
{
|
||||||
|
@ -44,9 +44,6 @@ or with the **optional** `"relays"` and/or `"account_paths"` attributes:
|
||||||
},
|
},
|
||||||
"relays": {
|
"relays": {
|
||||||
"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [ "wss://relay.example.com", "wss://relay2.example.com" ]
|
"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 `"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
|
## 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"`.
|
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.
|
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
|
### 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.
|
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.
|
||||||
|
|
Loading…
Reference in New Issue
Block a user