nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-22 08:25:53 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

clarify nip19 purpose.

Browse Source
This commit is contained in:
fiatjaf 2022-12-29 21:02:32 -03:00
parent a37a27afb9
commit 0ca9be8224
No known key found for this signature in database
GPG Key ID: BAD43C4BE5C1A3A1
2 changed files with 10 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
05.md
View File

@ -47,9 +47,9 @@ A client may implement support for finding users' public keys from _internet ide
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). 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).
### Public keys must be in Hex format ### Public keys must be in hex format
Keys must be returned in Hex format. Keys returned in npub format are not supported by this spec. 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.
### User Discovery implementation suggestion ### User Discovery implementation suggestion
@ -78,7 +78,6 @@ Users should ensure that their `/.well-known/nostr.json` is served with the HTTP
### Security Constraints ### Security Constraints
The `/.well-known/nostr.json` endpoint MUST NOT return any HTTP redirects. The `/.well-known/nostr.json` endpoint MUST NOT return any HTTP redirects.
Fetchers MUST ignore any HTTP redirects given by the `/.well-known/nostr.json` endpoint. Fetchers MUST ignore any HTTP redirects given by the `/.well-known/nostr.json` endpoint.

8
19.md
View File

@ -6,7 +6,9 @@ bech32-encoded entities
`draft` `optional` `author:jb55` `author:fiatjaf` `author:Semisol` `draft` `optional` `author:jb55` `author:fiatjaf` `author:Semisol`
This NIP specifies all bech32-encoded entities. This NIP standardizes bech32-formatted strings that can be used to display keys, ids and other information in clients. These formats are not meant to be used anywhere in the core protocol, they are only meant for displaying to users, copy-pasting, sharing, rendering QR codes and inputting data.
It is recommended that ids and keys are stored in either hex or binary format, since these formats are closer to what must actually be used the core protocol.
## Bare keys and ids ## Bare keys and ids
@ -50,3 +52,7 @@ These possible standardized `TLV` types are indicated here:
- pubkey: `3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d` - pubkey: `3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d`
- relay: `wss://r.x.com` - relay: `wss://r.x.com`
- relay: `wss://djbas.sadkb.com` - relay: `wss://djbas.sadkb.com`
## Notes
- `npub` keys MUST NOT be used in NIP-01 events or in NIP-05 JSON responses, only the hex format is supported there.