"user metadata" and fix table on readme.

3 files changed, 3 insertions, 3 deletions

diff --git a/01.md b/01.md
index 94db77a..60d9785 100644
--- a/01.md
+++ b/01.md
@@ -87,7 +87,7 @@ As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key
 
 Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. This NIP defines two basic kinds:
 
-- `0`: **user's metadata**: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. [Extra metadata fields](24.md#kind-0) may be set. A relay may delete older events once it gets a new one for the same pubkey.
+- `0`: **user metadata**: the `content` is set to a stringified JSON object `{name: <username>, about: <string>, picture: <url, string>}` describing the user who created the event. [Extra metadata fields](24.md#kind-0) may be set. A relay may delete older events once it gets a new one for the same pubkey.
 - `1`: **text note**: the `content` is set to the **plaintext** content of a note (anything the user wants to say). Content that must be parsed, such as Markdown and HTML, should not be used. Clients should also not parse content as those.
 
 And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation:
diff --git a/05.md b/05.md
index f3a051c..a1d488d 100644
--- a/05.md
+++ b/05.md
@@ -6,7 +6,7 @@ Mapping Nostr keys to DNS-based internet identifiers
 
 `final` `optional`
 
-On events of kind `0` (`user's metadata`) one can specify the key `"nip05"` with an [internet identifier](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (an email-like address) as the value. Although there is a link to a very liberal "internet identifier" specification above, NIP-05 assumes the `<local-part>` part will be restricted to the characters `a-z0-9-_.`, case-insensitive.
+On events of kind `0` (`user metadata`) one can specify the key `"nip05"` with an [internet identifier](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (an email-like address) as the value. Although there is a link to a very liberal "internet identifier" specification above, NIP-05 assumes the `<local-part>` part will be restricted to the characters `a-z0-9-_.`, case-insensitive.
 
 Upon seeing that, the client splits the identifier into `<local-part>` and `<domain>` and use these values to make a GET request to `https://<domain>/.well-known/nostr.json?name=<local-part>`.
 
diff --git a/README.md b/README.md
index 067c436..02773a5 100644
--- a/README.md
+++ b/README.md
@@ -90,7 +90,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 ## Event Kinds
 | kind          | description                | NIP                      |
 | ------------- | -------------------------- | ------------------------ |
-| `0`           | User's Metadata                   | [01](01.md)              |
+| `0`           | User Metadata              | [01](01.md)              |
 | `1`           | Short Text Note            | [01](01.md)              |
 | `2`           | Recommend Relay            | 01 (deprecated)          |
 | `3`           | Follows                    | [02](02.md)              |