2 files changed, 10 insertions, 5 deletions

diff --git a/05.md b/05.md
index fdf1101..b489b4b 100644
--- a/05.md
+++ b/05.md
@@ -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).
 
-### 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
 
@@ -78,7 +78,6 @@ Users should ensure that their `/.well-known/nostr.json` is served with the HTTP
 
 ### 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.
-
diff --git a/19.md b/19.md
index 8f05b67..b9973cf 100644
--- a/19.md
+++ b/19.md
@@ -6,7 +6,9 @@ bech32-encoded entities
 
 `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
 
@@ -50,3 +52,7 @@ These possible standardized `TLV` types are indicated here:
   - pubkey: `3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d`
   - relay: `wss://r.x.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.