7 files changed, 62 insertions, 20 deletions

diff --git a/01.md b/01.md
index d040666..e1e9444 100644
--- a/01.md
+++ b/01.md
@@ -16,8 +16,8 @@ The only object type that exists is the `event`, which has the following format
 
 ```json
 {
-  "id": <32-bytes sha256 of the the serialized event data>
-  "pubkey": <32-bytes hex-encoded public key of the event creator>,
+  "id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>
+  "pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
   "created_at": <unix timestamp in seconds>,
   "kind": <integer>,
   "tags": [
@@ -66,8 +66,8 @@ Clients can send 3 types of messages, which must be JSON arrays, according to th
   "kinds": <a list of a kind numbers>,
   "#e": <a list of event ids that are referenced in an "e" tag>,
   "#p": <a list of pubkeys that are referenced in a "p" tag>,
-  "since": <a timestamp, events must be newer than this to pass>,
-  "until": <a timestamp, events must be older than this to pass>,
+  "since": <an integer unix timestamp, events must be newer than this to pass>,
+  "until": <an integer unix timestamp, events must be older than this to pass>,
   "limit": <maximum number of events to be returned in the initial query>
 }
 ```
diff --git a/03.md b/03.md
index 578c351..3c5d764 100644
--- a/03.md
+++ b/03.md
@@ -10,11 +10,11 @@ When there is an OTS available it MAY be included in the existing event body und
 
 ```
 {
-  id: ...,
-  kind: ...,
+  "id": ...,
+  "kind": ...,
   ...,
   ...,
-  ots: <base64-encoded OTS file data>
+  "ots": <base64-encoded OTS file data>
 }
 ```
 
diff --git a/11.md b/11.md
index 2b26823..8cdb85e 100644
--- a/11.md
+++ b/11.md
@@ -12,13 +12,13 @@ When a relay receives an HTTP(s) request with an `Accept` header of `application
 
 ```json
 {
-  name: <string identifying relay>,
-  description: <string with detailed information>,
-  pubkey: <administrative contact pubkey>,
-  contact: <administrative alternate contact>,
-  supported_nips: <a list of NIP numbers supported by the relay>,
-  software: <string identifying relay software URL>,
-  version: <string version identifier>
+  "name": <string identifying relay>,
+  "description": <string with detailed information>,
+  "pubkey": <administrative contact pubkey>,
+  "contact": <administrative alternate contact>,
+  "supported_nips": <a list of NIP numbers supported by the relay>,
+  "software": <string identifying relay software URL>,
+  "version": <string version identifier>
 }
 ```
 
diff --git a/21.md b/21.md
new file mode 100644
index 0000000..2525bf1
--- /dev/null
+++ b/21.md
@@ -0,0 +1,20 @@
+NIP-21
+======
+
+`nostr:` URL scheme
+-------------------
+
+`draft` `optional` `author:fiatjaf`
+
+This NIP standardizes the usage of a common URL scheme for maximum interoperability and openness in the network.
+
+The scheme is `nostr:`.
+
+The identifiers that come after are expected to be the same as those defined in NIP-19 (except `nsec`).
+
+## Examples
+
+- `nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9`
+- `nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gpp4mhxue69uhhytnc9e3k7mgpz4mhxue69uhkg6nzv9ejuumpv34kytnrdaksjlyr9p`
+- `nostr:note1fntxtkcy9pjwucqwa9mddn7v03wwwsu9j330jj350nvhpky2tuaspk6nqc`
+- `nostr:nevent1qqstna2yrezu5wghjvswqqculvvwxsrcvu7uc0f78gan4xqhvz49d9spr3mhxue69uhkummnw3ez6un9d3shjtn4de6x2argwghx6egpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5nxnepm`
diff --git a/28.md b/28.md
index f37299e..0862e72 100644
--- a/28.md
+++ b/28.md
@@ -54,7 +54,7 @@ Clients SHOULD use [NIP-10](10.md) marked "e" tags to recommend a relay.
 ```json
 {
     "content": "{\"name\": \"Updated Demo Channel\", \"about\": \"Updating a test channel.\", \"picture\": \"https://placekitten.com/201/201\"}",
-    "tags": [["e", <channel_create_event_id> <relay-url>]],
+    "tags": [["e", <channel_create_event_id>, <relay-url>]],
     ...
 }
 ```
@@ -73,7 +73,7 @@ Root message:
 ```json
 {
     "content": <string>,
-    "tags": [["e", <kind_40_event_id> <relay-url> "root"]],
+    "tags": [["e", <kind_40_event_id>, <relay-url>, "root"]],
     ...
 }
 ```
@@ -84,8 +84,8 @@ Reply to another message:
 {
     "content": <string>,
     "tags": [
-        ["e", <kind_42_event_id> <relay-url> "reply"],
-        ["p", <pubkey> <relay-url>],
+        ["e", <kind_42_event_id>, <relay-url>, "reply"],
+        ["p", <pubkey>, <relay-url>],
         ...
     ],
     ...
diff --git a/33.md b/33.md
index db572ad..6b05bd0 100644
--- a/33.md
+++ b/33.md
@@ -10,10 +10,12 @@ This NIP adds a new event range that allows for replacement of events that have
 
 Implementation
 --------------
-A *parameterized replaceable event* is defined as an event with a kind `30000 <= n < 40000`.
+The value of a tag is defined as the first parameter of a tag after the tag name.
+
+A *parameterized replaceable event* is defined as an event with a kind `30000 <= n < 40000`.  
 Upon a parameterized replaceable event with a newer timestamp than the currently known latest
 replaceable event with the same kind and first `d` tag value being received, the old event
-SHOULD be discarded and replaced with the newer event.
+SHOULD be discarded and replaced with the newer event.  
 A missing or a `d` tag with no value should be interpreted equivalent to a `d` tag with the
 value as an empty string. Events from the same author with any of the following `tags`
 replace each other:
@@ -24,6 +26,9 @@ replace each other:
 * `"tags":[["d",""],["d","not empty"]]`: only first `d` tag is considered
 * `"tags":[["d"],["d","some value"]]`: only first `d` tag is considered
 * `"tags":[["e"]]`: same as no tags
+* `"tags":[["d","test","1"]]`: only the value is considered (`test`)
+
+Clients SHOULD NOT use `d` tags with multiple values and SHOULD include the `d` tag even if it has no value to allow querying using the `#d` filter.
 
 Client Behavior
 ---------------
diff --git a/README.md b/README.md
index 1576965..1ef0ec8 100644
--- a/README.md
+++ b/README.md
@@ -20,6 +20,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 - [NIP-16: Event Treatment](16.md)
 - [NIP-19: bech32-encoded entities](19.md)
 - [NIP-20: Command Results](20.md)
+- [NIP-21: `nostr:` URL scheme](21.md)
 - [NIP-22: Event created_at Limits](22.md)
 - [NIP-25: Reactions](25.md)
 - [NIP-26: Delegated Event Signing](26.md)
@@ -49,6 +50,8 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 | 22242       | Client Authentication       | [42](42.md)            |
 | 10000-19999 | Replaceable Events Reserved | [16](16.md)            |
 | 20000-29999 | Ephemeral Events Reserved   | [16](16.md)            |
+| 30000-39999 | Param. Repl. Events Reserved| [33](33.md)            |
+
 
 
 ## Message types
@@ -74,6 +77,20 @@ Please update these lists when proposing NIPs introducing new event kinds.
 
 When experimenting with kinds, keep in mind the classification introduced by [NIP-16](16.md).
 
+## Standardized Tags
+
+| name       | value                   | other parameters  | NIP                      |
+| ---------- | ----------------------- | ----------------- | ------------------------ |
+| e          | event id (hex)          | relay URL, marker | [1](01.md), [10](10.md)  |
+| p          | pubkey (hex)            | relay URL         | [1](01.md)               |
+| r          | a reference (URL, etc)  |                   | [12](12.md)              |
+| t          | hashtag                 |                   | [12](12.md)              |
+| g          | geohash                 |                   | [12](12.md)              |
+| nonce      | random                  |                   | [13](13.md)              |
+| subject    | subject                 |                   | [14](14.md)              |
+| d          | identifier              |                   | [33](33.md)              |
+| expiration | unix timestamp (string) |                   | [40](40.md)              |
+
 ## Criteria for acceptance of NIPs
 
 1. They should be implemented in at least two clients and one relay -- when applicable.