From 02e9aec1a6a80e394e04e5ffd39716cf4f4201d0 Mon Sep 17 00:00:00 2001 From: Blake Jakopovic Date: Sat, 25 Mar 2023 14:31:59 +0100 Subject: [PATCH] Update all NIPs to include 'depends' and 'mentions' tags --- 02.md | 2 +- 03.md | 2 +- 04.md | 2 +- 05.md | 2 +- 07.md | 2 +- 08.md | 2 +- 09.md | 2 +- 10.md | 7 +++---- 11.md | 6 +++--- 12.md | 6 +++--- 13.md | 10 +++++----- 14.md | 6 +++--- 15.md | 4 ++-- 16.md | 2 +- 19.md | 2 +- 20.md | 3 +-- 22.md | 2 +- 23.md | 14 +++++++------- 25.md | 3 +-- 26.md | 6 +++--- 28.md | 3 +-- 33.md | 8 ++++---- 36.md | 2 +- 39.md | 4 ++-- 40.md | 2 +- 42.md | 2 +- 46.md | 10 ++++------ 50.md | 22 +++++++++++----------- 51.md | 2 +- 56.md | 3 +-- 57.md | 6 +++--- 58.md | 2 +- 65.md | 2 +- 78.md | 2 +- 34 files changed, 74 insertions(+), 81 deletions(-) diff --git a/02.md b/02.md index 2f199080..e855f583 100644 --- a/02.md +++ b/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. diff --git a/03.md b/03.md index 3c5d764e..c5f0bf65 100644 --- a/03.md +++ b/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: diff --git a/04.md b/04.md index 60ec5e04..07182220 100644 --- a/04.md +++ b/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: diff --git a/05.md b/05.md index 992983f7..d3dd62ba 100644 --- a/05.md +++ b/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 `` part will be restricted to the characters `a-z0-9-_.`, case insensitive. diff --git a/07.md b/07.md index ad26d2fd..45472095 100644 --- a/07.md +++ b/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. diff --git a/08.md b/08.md index 113cb539..43b1ffdd 100644 --- a/08.md +++ b/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. diff --git a/09.md b/09.md index b0febc74..5f87ed90 100644 --- a/09.md +++ b/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. diff --git a/10.md b/10.md index 64947967..3387a9f8 100644 --- a/10.md +++ b/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", , ]` as per NIP-01. +`["e", , ]` as per [NIP-01](01.md). Where: * `` is the id of the event being referenced. * `` 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:
diff --git a/11.md b/11.md index f97193c2..eae02cf7 100644 --- a/11.md +++ b/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 diff --git a/12.md b/12.md index 74c9d81a..6e8ece0b 100644 --- a/12.md +++ b/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 `` 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 `` 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 --------------------------- diff --git a/13.md b/13.md index cf28d867..80764ba2 100644 --- a/13.md +++ b/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 diff --git a/14.md b/14.md index 0b37e8aa..3bdcea27 100644 --- a/14.md +++ b/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": ]` @@ -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. diff --git a/15.md b/15.md index 081a97d9..e911c447 100644 --- a/15.md +++ b/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 ---------- diff --git a/16.md b/16.md index 80a6b3d9..142a452e 100644 --- a/16.md +++ b/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. diff --git a/19.md b/19.md index 9d73458d..e9dd59fe 100644 --- a/19.md +++ b/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. diff --git a/20.md b/20.md index 7e97dd91..245d94ee 100644 --- a/20.md +++ b/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. diff --git a/22.md b/22.md index fb29e6ac..58da1d21 100644 --- a/22.md +++ b/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). diff --git a/23.md b/23.md index 0648a354..ae99d904 100644 --- a/23.md +++ b/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. diff --git a/25.md b/25.md index 5ab1553c..9c031419 100644 --- a/25.md +++ b/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. diff --git a/26.md b/26.md index 11468c07..f9ce4933 100644 --- a/26.md +++ b/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 diff --git a/28.md b/28.md index 169ae4f4..0ae2dfa8 100644 --- a/28.md +++ b/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. diff --git a/33.md b/33.md index 60f3da66..3883989c 100644 --- a/33.md +++ b/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", "", ""]`). 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", "::", ""]`. diff --git a/36.md b/36.md index 1223e53c..2d6d61ad 100644 --- a/36.md +++ b/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. diff --git a/39.md b/39.md index b84603c9..5c0950fc 100644 --- a/39.md +++ b/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": , diff --git a/40.md b/40.md index 274ee801..26280258 100644 --- a/40.md +++ b/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. diff --git a/42.md b/42.md index 9b0c45b4..63e0080f 100644 --- a/42.md +++ b/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. diff --git a/46.md b/46.md index 90fa1a06..ae1bd704 100644 --- a/46.md +++ b/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://&relay=&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 diff --git a/50.md b/50.md index 5bda3559..72123908 100644 --- a/50.md +++ b/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. -Specifics of the search algorithms will differ between event kinds, this NIP only describes a general +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 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": } ``` -`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. +`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 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 diff --git a/51.md b/51.md index b4143ada..7e100d92 100644 --- a/51.md +++ b/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. diff --git a/56.md b/56.md index 55ee1a2e..df086c1c 100644 --- a/56.md +++ b/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. diff --git a/57.md b/57.md index 79f167c6..3c458f36 100644 --- a/57.md +++ b/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. diff --git a/58.md b/58.md index 2fa44066..37d73a25 100644 --- a/58.md +++ b/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: diff --git a/65.md b/65.md index 4c7a6a53..777ee527 100644 --- a/65.md +++ b/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. diff --git a/78.md b/78.md index 175f66b1..a835f007 100644 --- a/78.md +++ b/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.