Update all NIPs to include 'depends' and 'mentions' tags

02.md

@@ -4,7 +4,7 @@ NIP-02
 Contact List and Petnames
 -------------------------
 
-`final` `optional` `author:fiatjaf` `author:arcbtc`
+`final` `optional` `author:fiatjaf` `author:arcbtc` `depends:01`
 
 A special event with kind `3`, meaning "contact list" is defined as having a list of `p` tags, one for each of the followed/known profiles one is following.
 

03.md

@@ -4,7 +4,7 @@ NIP-03
 OpenTimestamps Attestations for Events
 --------------------------------------
 
-`draft` `optional` `author:fiatjaf`
+`draft` `optional` `author:fiatjaf` `depends:01`
 
 When there is an OTS available it MAY be included in the existing event body under the `ots` key:
 

04.md

@@ -4,7 +4,7 @@ NIP-04
 Encrypted Direct Message
 ------------------------
 
-`final` `optional` `author:arcbtc`
+`final` `optional` `author:arcbtc` `depends:01`
 
 A special event with kind `4`, meaning "encrypted direct message". It is supposed to have the following attributes:
 

05.md

@@ -4,7 +4,7 @@ NIP-05
 Mapping Nostr keys to DNS-based internet identifiers
 ----------------------------------------------------
 
-`final` `optional` `author:fiatjaf` `author:mikedilger`
+`final` `optional` `author:fiatjaf` `author:mikedilger``depends:01` `mentions:19`
 
 On events of kind `0` (`set_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.
 

07.md

@@ -4,7 +4,7 @@ NIP-07
 `window.nostr` capability for web browsers
 ------------------------------------------
 
-`draft` `optional` `author:fiatjaf`
+`draft` `optional` `author:fiatjaf` `depends:04`
 
 The `window.nostr` object may be made available by web browsers or extensions and websites or web-apps may make use of it after checking its availability.
 

08.md

@@ -4,7 +4,7 @@ NIP-08
 Handling Mentions
 -----------------
 
-`final` `optional` `author:fiatjaf` `author:scsibug`
+`final` `optional` `author:fiatjaf` `author:scsibug` `depends:01`
 
 This document standardizes the treatment given by clients of inline mentions of other events and pubkeys inside the content of `text_note`s.
 

09.md

@@ -4,7 +4,7 @@ NIP-09
 Event Deletion
 --------------
 
-`draft` `optional` `author:scsibug`
+`draft` `optional` `author:scsibug` `depends:01`
 
 A special event with kind `5`, meaning "deletion" is defined as having a list of one or more `e` tags, each referencing an event the author is requesting to be deleted.
 

10.md

@@ -1,11 +1,10 @@
 NIP-10
 ======
 
-
 On "e" and "p" tags in Text Events (kind 1).
 --------------------------------------------
 
-`draft` `optional` `author:unclebobmartin`
+`draft` `optional` `author:unclebobmartin` `depends:01`
 
 ## Abstract
 This NIP describes how to use "e" and "p" tags in text events, especially those that are replies to other text events.  It helps clients thread the replies into a tree rooted at the original event.
@@ -13,13 +12,13 @@ This NIP describes how to use "e" and "p" tags in text events, especially those
 ## Positional "e" tags (DEPRECATED)
 >This scheme is in common use; but should be considered deprecated.
 
-`["e", <event-id>, <relay-url>]`  as per NIP-01.
+`["e", <event-id>, <relay-url>]`  as per [NIP-01](01.md).
 
 Where:
 
  * `<event-id>` is the id of the event being referenced.
  * `<relay-url>` is the URL of a recommended relay associated with the reference.  Many clients treat this field as optional.
- 
+
 **The positions of the "e" tags within the event denote specific meanings as follows**:
 
  * No "e" tag: <br>

11.md

@@ -4,7 +4,7 @@ NIP-11
 Relay Information Document
 ---------------------------
 
-`draft` `optional` `author:scsibug` `author:doc-hex` `author:cameri`
+`draft` `optional` `author:scsibug` `author:doc-hex` `author:cameri` `depends:13` `depends:42` `mentions:01` `mentions:04``mentions:09` `mentions:16`
 
 Relays may provide server metadata to clients to inform them of capabilities, administrative contacts, and various server attributes.  This is made available as a JSON document over HTTP, on the same URI as the relay's websocket.
 
@@ -47,7 +47,7 @@ An alternative contact may be listed under the `contact` field as well, with the
 
 ### Supported NIPs ###
 
-As the Nostr protocol evolves, some functionality may only be available by relays that implement a specific `NIP`.  This field is an array of the integer identifiers of `NIP`s that are implemented in the relay.  Examples would include `1`, for `"NIP-01"` and `9`, for `"NIP-09"`.  Client-side `NIPs` SHOULD NOT be advertised, and can be ignored by clients.
+As the Nostr protocol evolves, some functionality may only be available by relays that implement a specific `NIP`.  This field is an array of the integer identifiers of `NIP`s that are implemented in the relay.  Examples would include `1` for [NIP-01](01.md), and `9`, for [NIP-09](09.md).  Client-side `NIPs` SHOULD NOT be advertised, and can be ignored by clients.
 
 ### Software ###
 
@@ -118,7 +118,7 @@ field of any event. This is a count of unicode characters. After
 serializing into JSON it may be larger (in bytes), and is still
 subject to the `max_message_length`, if defined.
 
-- `min_pow_difficulty`: new events will require at least this difficulty of PoW, 
+- `min_pow_difficulty`: new events will require at least this difficulty of PoW,
 based on [NIP-13](13.md), or they will be rejected by this server.
 
 - `auth_required`: this relay requires [NIP-42](42.md) authentication

12.md

@@ -4,11 +4,11 @@ NIP-12
 Generic Tag Queries
 -------------------
 
-`draft` `optional` `author:scsibug` `author:fiatjaf`
+`draft` `optional` `author:scsibug` `author:fiatjaf` `depends:01`
 
-Relays may support subscriptions over arbitrary tags.  `NIP-01` requires relays to respond to queries for `e` and `p` tags.  This NIP allows any single-letter tag present in an event to be queried.
+Relays may support subscriptions over arbitrary tags. [NIP-01](01.md) requires relays to respond to queries for `e` and `p` tags.  This NIP allows any single-letter tag present in an event to be queried.
 
-The `<filters>` object described in `NIP-01` is expanded to contain arbitrary keys with a `#` prefix.  Any single-letter key in a filter beginning with `#` is a tag query, and MUST have a value of an array of strings.  The filter condition matches if the event has a tag with the same name, and there is at least one tag value in common with the filter and event.  The tag name is the letter without the `#`, and the tag value is the second element. Subsequent elements are ignored for the purposes of tag queries.
+The `<filters>` object described in [NIP-01](01.md) is expanded to contain arbitrary keys with a `#` prefix.  Any single-letter key in a filter beginning with `#` is a tag query, and MUST have a value of an array of strings.  The filter condition matches if the event has a tag with the same name, and there is at least one tag value in common with the filter and event.  The tag name is the letter without the `#`, and the tag value is the second element. Subsequent elements are ignored for the purposes of tag queries.
 
 Example Subscription Filter
 ---------------------------

13.md

@@ -4,22 +4,22 @@ NIP-13
 Proof of Work
 -------------
 
-`draft` `optional` `author:jb55` `author:cameri`
+`draft` `optional` `author:jb55` `author:cameri` `depends:01`
 
 This NIP defines a way to generate and interpret Proof of Work for nostr notes. Proof of Work (PoW) is a way to add a proof of computational work to a note. This is a bearer proof that all relays and clients can universally validate with a small amount of code. This proof can be used as a means of spam deterrence.
 
-`difficulty` is defined to be the number of leading zero bits in the `NIP-01` id. For example, an id of `000000000e9d97a1ab09fc381030b346cdd7a142ad57e6df0b46dc9bef6c7e2d` has a difficulty of `36` with `36` leading 0 bits.
+`difficulty` is defined to be the number of leading zero bits in the [NIP-01](01.md) id. For example, an id of `000000000e9d97a1ab09fc381030b346cdd7a142ad57e6df0b46dc9bef6c7e2d` has a difficulty of `36` with `36` leading 0 bits.
 
 Mining
 ------
 
-To generate PoW for a `NIP-01` note, a `nonce` tag is used:
+To generate PoW for a [NIP-01](01.md) note, a `nonce` tag is used:
 
 ```json
 {"content": "It's just me mining my own business", "tags": [["nonce", "1", "20"]]}
 ```
 
-When mining, the second entry to the nonce tag is updated, and then the id is recalculated (see [NIP-01](./01.md)). If the id has the desired number of leading zero bits, the note has been mined. It is recommended to update the `created_at` as well during this process.
+When mining, the second entry to the nonce tag is updated, and then the id is recalculated (see [NIP-01](01.md)). If the id has the desired number of leading zero bits, the note has been mined. It is recommended to update the `created_at` as well during this process.
 
 The third entry to the nonce tag `SHOULD` contain the target difficulty. This allows clients to protect against situations where bulk spammers targeting a lower difficulty get lucky and match a higher difficulty. For example, if you require 40 bits to reply to your thread and see a committed target of 30, you can safely reject it even if the note has 40 bits difficulty. Without a committed target difficulty you could not reject it. Committing to a target difficulty is something all honest miners should be ok with, and clients `MAY` reject a note matching a target difficulty if it is missing a difficulty commitment.
 
@@ -90,4 +90,4 @@ $ echo '["REQ", "subid", {"ids": ["000000000"]}]'  | websocat wss://some-relay.c
 Delegated Proof of Work
 -----------------------
 
-Since the `NIP-01` note id does not commit to any signature, PoW can be outsourced to PoW providers, perhaps for a fee. This provides a way for clients to get their messages out to PoW-restricted relays without having to do any work themselves, which is useful for energy constrained devices like on mobile
+Since the [NIP-01](01.md) note id does not commit to any signature, PoW can be outsourced to PoW providers, perhaps for a fee. This provides a way for clients to get their messages out to PoW-restricted relays without having to do any work themselves, which is useful for energy constrained devices like on mobile

14.md

@@ -4,9 +4,9 @@ NIP-14
 Subject tag in Text events.
 ---------------------------
 
-`draft` `optional` `author:unclebobmartin`
+`draft` `optional` `author:unclebobmartin` `depends:01`
 
-This NIP defines the use of the "subject" tag in text (kind: 1) events.  
+This NIP defines the use of the "subject" tag in text (kind: 1) events.
 (implemented in more-speech)
 
 `["subject": <string>]`
@@ -14,6 +14,6 @@ This NIP defines the use of the "subject" tag in text (kind: 1) events.
 Browsers often display threaded lists of messages.  The contents of the subject tag can be used in such lists, instead of the more ad hoc approach of using the first few words of the message.  This is very similar to the way email browsers display lists of incoming emails by subject rather than by contents.
 
 When replying to a message with a subject, clients SHOULD replicate the subject tag.  Clients MAY adorn the subject to denote
-that it is a reply.  e.g. by prepending "Re:".  
+that it is a reply.  e.g. by prepending "Re:".
 
 Subjects should generally be shorter than 80 chars.  Long subjects will likely be trimmed by clients.

15.md

@@ -4,7 +4,7 @@ NIP-15
 End of Stored Events Notice
 ---------------------------
 
-`final` `optional` `author:Semisol`
+`final` `optional` `author:Semisol` `depends:01` `depends:11`
 
 Relays may support notifying clients when all stored events have been sent.
 
@@ -13,7 +13,7 @@ If a relay supports this NIP, the relay SHOULD send the client a `EOSE` message
 Client Behavior
 ---------------
 
-Clients SHOULD use the `supported_nips` field to learn if a relay supports end of stored events notices.
+Clients SHOULD use the `supported_nips` field from [NIP-11](11.md) to learn if a relay supports end of stored events notices.
 
 Motivation
 ----------

16.md

@@ -4,7 +4,7 @@ NIP-16
 Event Treatment
 ---------------
 
-`draft` `optional` `author:Semisol`
+`draft` `optional` `author:Semisol` `depends:11`
 
 Relays may decide to allow replaceable and/or ephemeral events.
 

19.md

@@ -4,7 +4,7 @@ NIP-19
 bech32-encoded entities
 -----------------------
 
-`draft` `optional` `author:jb55` `author:fiatjaf` `author:Semisol`
+`draft` `optional` `author:jb55` `author:fiatjaf` `author:Semisol` `depends:01` `depends:33`
 
 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.
 

20.md

@@ -1,11 +1,10 @@
 NIP-20
 ======
 
-
 Command Results
 ---------------
 
-`draft` `optional` `author:jb55`
+`draft` `optional` `author:jb55` `depends:01`
 
 When submitting events to relays, clients currently have no way to know if an event was successfully committed to the database. This NIP introduces the concept of command results which are like NOTICE's except provide more information about if an event was accepted or rejected.
 

22.md

@@ -4,7 +4,7 @@ NIP-22
 Event `created_at` Limits
 ---------------------------
 
-`draft` `optional` `author:jeffthibault` `author:Giszmo`
+`draft` `optional` `author:jeffthibault` `author:Giszmo` `depends:01` `depends:20`
 
 Relays may define both upper and lower limits within which they will consider an event's `created_at` to be acceptable. Both the upper and lower limits MUST be unix timestamps in seconds as defined in [NIP-01](01.md).
 

23.md

@@ -4,9 +4,9 @@ NIP-23
 Long-form Content
 -----------------
 
-`draft` `optional` `author:fiatjaf`
+`draft` `optional` `author:fiatjaf` `depends:08` `depends:12` `depends:19` `depends:21` `depends:33`
 
-This NIP defines `kind:30023` (a parameterized replaceable event according to NIP-33) for long-form text content, generally referred to as "articles" or "blog posts".
+This NIP defines `kind:30023` (a parameterized replaceable event according to [NIP-33](33.md)) for long-form text content, generally referred to as "articles" or "blog posts".
 
 "Social" clients that deal primarily with `kind:1` notes should not be expected to implement this NIP.
 
@@ -16,7 +16,7 @@ The `.content` of these events should be a string text in Markdown syntax.
 
 ### Metadata
 
-For the date of the last update the `.created_at` field should be used, for "tags"/"hashtags" (i.e. topics about which the event might be of relevance) the `"t"` event tag should be used, as per NIP-12.
+For the date of the last update the `.created_at` field should be used, for "tags"/"hashtags" (i.e. topics about which the event might be of relevance) the `"t"` event tag should be used, as per [NIP-12](12.md).
 
 Other metadata fields can be added as tags to the event as necessary. Here we standardize 4 that may be useful, although they remain strictly optional:
 
@@ -27,17 +27,17 @@ Other metadata fields can be added as tags to the event as necessary. Here we st
 
 ### Editability
 
-These articles are meant to be editable, so they should make use of the replaceability feature of NIP-33 and include a `"d"` tag with an identifier for the article. Clients should take care to only publish and read these events from relays that implement that. If they don't do that they should also take care to hide old versions of the same article they may receive.
+These articles are meant to be editable, so they should make use of the replaceability feature of [NIP-33](33.md) and include a `"d"` tag with an identifier for the article. Clients should take care to only publish and read these events from relays that implement that. If they don't do that they should also take care to hide old versions of the same article they may receive.
 
 ### Linking
 
-The article may be linked to using the NIP-19 `naddr` code along with the `"a"` tag (see NIP-33 and NIP-19).
+The article may be linked to using the [NIP-19](19.md) `naddr` code along with the `"a"` tag (see [NIP-33](33.md) and [NIP-19](19.md)).
 
 ### References
 
-Clients that support publishing NIP-23 events should implement support for parsing pasted NIP-19 `naddr` identifiers and adding them automatically to the list of `.tags` of the event, replacing the actual content with a string like `#[tag_index]` in the same way as NIP-08 -- or, if the reference is in the form of a URL (for example, `[click here](naddr1...)`) then they should be replaced with just the tag number directly as if link with that name existed at the bottom of the Markdown (for example, `[click here][0]`).
+Clients that support publishing `NIP-23` events should implement support for parsing pasted [NIP-19](19.md) `naddr` identifiers and adding them automatically to the list of `.tags` of the event, replacing the actual content with a string like `#[tag_index]` in the same way as [NIP-08](08.md) -- or, if the reference is in the form of a URL (for example, `[click here](naddr1...)`) then they should be replaced with just the tag number directly as if link with that name existed at the bottom of the Markdown (for example, `[click here][0]`).
 
-Reader clients should parse the Markdown and replace these references with either internal links so the referenced events can be accessed directly, with NIP-21 `nostr:naddr1...` links or direct links to web clients that will handle these references.
+Reader clients should parse the Markdown and replace these references with either internal links so the referenced events can be accessed directly, with [NIP-21](21.md) `nostr:naddr1...` links or direct links to web clients that will handle these references.
 
 The idea here is that having these tags is that reader clients can display a list of backreferences at the bottom when one article mentions another.
 

25.md

@@ -1,11 +1,10 @@
-
 NIP-25
 ======
 
 Reactions
 ---------
 
-`draft` `optional` `author:jb55`
+`draft` `optional` `author:jb55` `depends:01`
 
 A reaction is a `kind 7` note that is used to react to other notes.
 

26.md

@@ -1,14 +1,14 @@
-NIP: 26
+NIP-26
 =======
 
 Delegated Event Signing
 -----
 
-`draft` `optional` `author:markharding` `author:minds`
+`draft` `optional` `author:markharding` `author:minds` `depends:01`
 
 This NIP defines how events can be delegated so that they can be signed by other keypairs.
 
-Another application of this proposal is to abstract away the use of the 'root' keypairs when interacting with clients. For example, a user could generate new keypairs for each client they wish to use and authorize those keypairs to generate events on behalf of their root pubkey, where the root keypair is stored in cold storage. 
+Another application of this proposal is to abstract away the use of the 'root' keypairs when interacting with clients. For example, a user could generate new keypairs for each client they wish to use and authorize those keypairs to generate events on behalf of their root pubkey, where the root keypair is stored in cold storage.
 
 #### Introducing the 'delegation' tag
 

28.md

@@ -1,11 +1,10 @@
-
 NIP-28
 ======
 
 Public Chat
 -----------
 
-`draft` `optional` `author:ChristopherDavid` `author:fiatjaf` `author:jb55` `author:Cameri`
+`draft` `optional` `author:ChristopherDavid` `author:fiatjaf` `author:jb55` `author:Cameri` `depends:01`
 
 This NIP defines new event kinds for public chat channels, channel messages, and basic client-side moderation.
 

33.md

@@ -4,9 +4,9 @@ NIP-33
 Parameterized Replaceable Events
 --------------------------------
 
-`draft` `optional` `author:Semisol` `author:Kukks` `author:Cameri` `author:Giszmo`
+`draft` `optional` `author:Semisol` `author:Kukks` `author:Cameri` `author:Giszmo` `depends:01` `depends:19` `mentions:12` `mentions:16`
 
-This NIP adds a new event range that allows for replacement of events that have the same `d` tag and kind unlike NIP-16 which only replaced by kind.
+This NIP adds a new event range that allows for replacement of events that have the same `d` tag and kind unlike [NIP-16](16.md) which only replaced by kind.
 
 Implementation
 --------------
@@ -33,13 +33,13 @@ Clients SHOULD NOT use `d` tags with multiple values and SHOULD include the `d`
 Referencing and tagging
 -----------------------
 
-Normally (as per NIP-01, NIP-12) the `"p"` tag is used for referencing public keys and the
+Normally (as per [NIP-01](01.md), [NIP-12](12.md)) the `"p"` tag is used for referencing public keys and the
 `"e"` tag for referencing event ids and the `note`, `npub`, `nprofile` or `nevent` are their
 equivalents for event tags (i.e. an `nprofile` is generally translated into a tag
 `["p", "<event hex id>", "<relay url>"]`).
 
 To support linking to parameterized replaceable events, the `naddr` code is introduced on
-NIP-19. It includes the public key of the event author and the `d` tag (and relays) such that
+[NIP-19](19.md). It includes the public key of the event author and the `d` tag (and relays) such that
 the referenced combination of public key and `d` tag can be found.
 
 The equivalent in `tags` to the `naddr` code is the tag `"a"`, comprised of `["a", "<kind>:<pubkey>:<d-identifier>", "<relay url>"]`.

36.md

@@ -4,7 +4,7 @@ NIP-36
 Sensitive Content / Content Warning
 -----------------------------------
 
-`draft` `optional` `author:fernandolguevara`
+`draft` `optional` `author:fernandolguevara` `depends:01`
 
 The `content-warning` tag enables users to specify if the event's content needs to be approved by readers to be shown.
 Clients can hide the content until the user acts on it.

39.md

@@ -4,7 +4,7 @@ NIP-39
 External Identities in Profiles
 -------------------------------
 
-`draft` `optional` `author:pseudozach` `author:Semisol`
+`draft` `optional` `author:pseudozach` `author:Semisol` `depends:01`
 
 ## Abstract
 
@@ -12,7 +12,7 @@ Nostr protocol users may have other online identities such as usernames, profile
 
 ## `i` tag on a metadata event
 
-A new optional `i` tag is introduced for `kind 0` metadata event contents in addition to name, about, picture fields as included in [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md):
+A new optional `i` tag is introduced for `kind 0` metadata event contents in addition to name, about, picture fields as included in [NIP-01](01.md):
 ```json
 {
     "id": <id>,

40.md

@@ -4,7 +4,7 @@ NIP-40
 Expiration Timestamp
 -----------------------------------
 
-`draft` `optional` `author:0xtlt`
+`draft` `optional` `author:0xtlt` `depends:01` `depends:11`
 
 The `expiration` tag enables users to specify a unix timestamp at which the message SHOULD be considered expired (by relays and clients) and SHOULD be deleted by relays.
 

42.md

@@ -4,7 +4,7 @@ NIP-42
 Authentication of clients to relays
 -----------------------------------
 
-`draft` `optional` `author:Semisol` `author:fiatjaf`
+`draft` `optional` `author:Semisol` `author:fiatjaf` `depends:01`
 
 This NIP defines a way for clients to authenticate to relays by signing an ephemeral event.
 

46.md

@@ -4,7 +4,7 @@ NIP-46
 Nostr Connect
 ------------------------
 
-`draft` `optional` `author:tiero` `author:giowe` `author:vforvalerio87`
+`draft` `optional` `author:tiero` `author:giowe` `author:vforvalerio87` `depends:04` `depends:26`
 
 ## Rationale
 
@@ -121,12 +121,12 @@ nostrconnect://b889ff5b1513b641e2a139f661a661364979c5beee91842f8f0ef42ab558e9d4?
 
 ## Flows
 
-The `content` field contains encrypted message as specified by [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md). The `kind` chosen is `24133`.
+The `content` field contains encrypted message as specified by [NIP04](04.md). The `kind` chosen is `24133`.
 
 ### Connect
 
 1. User clicks on **"Connect"** button on a website or scan it with a QR code
-2. It will show an URI to open a "nostr connect" enabled **Signer** 
+2. It will show an URI to open a "nostr connect" enabled **Signer**
 3. In the URI there is a pubkey of the **App** ie. `nostrconnect://<pubkey>&relay=<relay>&metadata=<metadata>`
 4. The **Signer** will send a message to ACK the `connect` request, along with his public key
 
@@ -157,6 +157,4 @@ The `content` field contains encrypted message as specified by [NIP04](https://g
 
 1. The **App** will send a message with metadata to the **Signer** with a `delegate` request along with the **conditions** query string and the **pubkey** of the **App** to be delegated.
 2. The **Signer** will show a popup to the user to delegate the **App** to sign on his behalf
-3. The **Signer** will send back a message with the signed [NIP-26 delegation token](https://github.com/nostr-protocol/nips/blob/master/26.md) or reject it
+3. The **Signer** will send back a message with the signed [NIP-26 delegation token](26.md) or reject it
-
-

50.md

@@ -4,15 +4,15 @@ NIP-50
 Search Capability
 -----------------
 
-`draft` `optional` `author:brugeman` `author:mikedilger` `author:fiatjaf`
+`draft` `optional` `author:brugeman` `author:mikedilger` `author:fiatjaf` `depends:01` `depends:11`
 
 ## Abstract
 
-Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids. 
+Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids.
-Specifics of the search algorithms will differ between event kinds, this NIP only describes a general 
+Specifics of the search algorithms will differ between event kinds, this NIP only describes a general
 extensible framework for performing such queries.
 
-## `search` filter field 
+## `search` filter field
 
 A new `search` field is introduced for `REQ` messages from clients:
 ```json
@@ -21,21 +21,21 @@ A new `search` field is introduced for `REQ` messages from clients:
   "search": <string>
 }
 ```
-`search` field is a string describing a query in a human-readable form, i.e. "best nostr apps". 
+`search` field is a string describing a query in a human-readable form, i.e. "best nostr apps".
-Relays SHOULD interpret the query to the best of their ability and return events that match it. 
+Relays SHOULD interpret the query to the best of their ability and return events that match it.
 Relays SHOULD perform matching against `content` event field, and MAY perform
-matching against other fields if that makes sense in the context of a specific kind. 
+matching against other fields if that makes sense in the context of a specific kind.
 
-A query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore 
+A query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore
 extensions they don't support.
 
-Clients may specify several search filters, i.e. `["REQ", "", { "search": "orange" }, { "kinds": [1, 2], "search": "purple" }]`. Clients may 
+Clients may specify several search filters, i.e. `["REQ", "", { "search": "orange" }, { "kinds": [1, 2], "search": "purple" }]`. Clients may
 include `kinds`, `ids` and other filter field to restrict the search results to particular event kinds.
 
-Clients SHOULD use the supported_nips field to learn if a relay supports `search` filter. Clients MAY send `search` 
+Clients SHOULD use the supported_nips field to learn if a relay supports `search` filter. Clients MAY send `search`
 filter queries to any relay, if they are prepared to filter out extraneous responses from relays that do not support this NIP.
 
-Clients SHOULD query several relays supporting this NIP to compensate for potentially different 
+Clients SHOULD query several relays supporting this NIP to compensate for potentially different
 implementation details between relays.
 
 Clients MAY verify that events returned by a relay match the specified query in a way that suits the

51.md

@@ -4,7 +4,7 @@ NIP-51
 Lists
 -------------------------
 
-`draft` `optional` `author:fiatjaf` `author:arcbtc` `author:monlovesmango` `author:eskema` `depends:33`
+`draft` `optional` `author:fiatjaf` `author:arcbtc` `author:monlovesmango` `author:eskema` `depends:01` `depends:04` `depends:02` `depends:16` `depends:33`
 
 A "list" event is defined as having a list of public and/or private tags. Public tags will be listed in the event `tags`. Private tags will be encrypted in the event `content`. Encryption for private tags will use [NIP-04 - Encrypted Direct Message](04.md) encryption, using the list author's private and public key for the shared secret. A distinct event kind should be used for each list type created.
 

56.md

@@ -1,11 +1,10 @@
-
 NIP-56
 ======
 
 Reporting
 ---------
 
-`draft` `optional` `author:jb55`
+`draft` `optional` `author:jb55` `depends:01`
 
 A report is a `kind 1984` note that is used to report other notes for spam,
 illegal and explicit content.

57.md

@@ -4,7 +4,7 @@ NIP-57
 Lightning Zaps
 --------------
 
-`draft` `optional` `author:jb55` `author:kieran`
+`draft` `optional` `author:jb55` `author:kieran` `depends:23` `depends:33`
 
 This NIP defines a new note type called a lightning zap of kind `9735`. These represent paid lightning invoice receipts sent by a lightning node called the `zapper`. We also define another note type of kind `9734` which are `zap request` notes, which will be described in this document.
 
@@ -30,7 +30,7 @@ Having lightning receipts on nostr allows clients to display lightning payments
 
 3. Clients may choose to display a lightning zap button on each post or on the users profile, if the user's lnurl pay request endpoint supports nostr, the client SHOULD generate a `zap invoice` instead of a normal lnurl invoice.
 
-4. To generate a `zap invoice`, call the `callback` url with `amount` set to the milli-satoshi amount value. A `nostr` querystring value MUST be set as well. It is a uri-encoded `zap request` note signed by the user's key. The `zap request` note contains an `e` tag of the note it is zapping, and a `p` tag of the target user's pubkey. The `e` tag is optional which allows profile tipping. An optional `a` tag allows tipping parameterized replaceable events such as NIP-23 long-form notes. The `zap request` note must also have a `relays` tag, which is gathered from the user's configured relays. The `zap request` note SHOULD contain an `amount` tag, which is the milli-satoshi value of the zap which clients SHOULD verify being equal to the amount of the invoice. The `content` MAY be an additional comment from the user which can be displayed when listing zaps on posts and profiles.
+4. To generate a `zap invoice`, call the `callback` url with `amount` set to the milli-satoshi amount value. A `nostr` querystring value MUST be set as well. It is a uri-encoded `zap request` note signed by the user's key. The `zap request` note contains an `e` tag of the note it is zapping, and a `p` tag of the target user's pubkey. The `e` tag is optional which allows profile tipping. An optional `a` tag allows tipping parameterized replaceable events such as [NIP-23](23.md) long-form notes. The `zap request` note must also have a `relays` tag, which is gathered from the user's configured relays. The `zap request` note SHOULD contain an `amount` tag, which is the milli-satoshi value of the zap which clients SHOULD verify being equal to the amount of the invoice. The `content` MAY be an additional comment from the user which can be displayed when listing zaps on posts and profiles.
 
 5. Pay this invoice or pass it to an app that can pay the invoice. Once it's paid, a `zap note` will be created by the `zapper`.
 
@@ -58,7 +58,7 @@ The lnurl server will need some additional pieces of information so that clients
 
 	f. If there is an `amount` tag, it MUST be equal to the `amount` query parameter.
 
-	g. If there is an `a` tag, it MUST be a valid NIP-33 event coordinate
+	g. If there is an `a` tag, it MUST be a valid [NIP-33](33.md) event coordinate
 
 5. If valid, fetch a description hash invoice where the description is this note and this note only. No additional lnurl metadata is included in the description.
 

58.md

@@ -4,7 +4,7 @@ NIP-58
 Badges
 ------
 
-`draft` `optional` `author:cameri`
+`draft` `optional` `author:cameri` `depends:01` `depends:33` `mentions:13`
 
 Three special events are used to define, award and display badges in
 user profiles:

65.md

@@ -4,7 +4,7 @@ NIP-65
 Relay List Metadata
 -------------------
 
-`draft` `optional` `author:mikedilger`
+`draft` `optional` `author:mikedilger` `depends:01` `depends:16` `mentions:02`
 
 A special replaceable event meaning "Relay List Metadata" is defined as an event with kind `10002` having a list of `r` tags, one for each relay the author uses to either read or write to.
 

78.md

@@ -4,7 +4,7 @@ NIP-78
 Arbitrary custom app data
 -------------------------
 
-`draft` `optional` `author:sandwich` `author:fiatjaf`
+`draft` `optional` `author:sandwich` `author:fiatjaf` `depends:33`
 
 The goal of this NIP is to enable [remoteStorage](https://remotestorage.io/)-like capabilities for custom applications that do not care about interoperability.