diff options
| -rw-r--r-- | 44.md | 2 | ||||
| -rw-r--r-- | 54.md | 20 |
2 files changed, 14 insertions, 8 deletions
| @@ -142,6 +142,8 @@ validation rules, refer to BIP-340. | |||
| 142 | The operation produces a shared point, and we encode the shared point's 32-byte x coordinate, using method | 142 | The operation produces a shared point, and we encode the shared point's 32-byte x coordinate, using method |
| 143 | `bytes(P)` from BIP340. Private and public keys must be validated as per BIP340: pubkey must be a valid, | 143 | `bytes(P)` from BIP340. Private and public keys must be validated as per BIP340: pubkey must be a valid, |
| 144 | on-curve point, and private key must be a scalar in range `[1, secp256k1_order - 1]`. | 144 | on-curve point, and private key must be a scalar in range `[1, secp256k1_order - 1]`. |
| 145 | NIP44 doesn't do hashing of the output: keep this in mind, because some libraries hash it using sha256. | ||
| 146 | As an example, in libsecp256k1, unhashed version is available in `secp256k1_ec_pubkey_tweak_mul` | ||
| 145 | - Operators | 147 | - Operators |
| 146 | - `x[i:j]`, where `x` is a byte array and `i, j <= 0` returns a `(j - i)`-byte array with a copy of the | 148 | - `x[i:j]`, where `x` is a byte array and `i, j <= 0` returns a `(j - i)`-byte array with a copy of the |
| 147 | `i`-th byte (inclusive) to the `j`-th byte (exclusive) of `x`. | 149 | `i`-th byte (inclusive) to the `j`-th byte (exclusive) of `x`. |
| @@ -6,7 +6,7 @@ Wiki | |||
| 6 | 6 | ||
| 7 | `draft` `optional` | 7 | `draft` `optional` |
| 8 | 8 | ||
| 9 | This NIP defines `kind:30818` (an _addressable event_) for long-form text content similar to [NIP-23](23.md), but with one important difference: articles are meant to be descriptions, or encyclopedia entries, of particular subjects, and it's expected that multiple people will write articles about the exact same subjects, with either small variations or completely independent content. | 9 | This NIP defines `kind:30818` (an _addressable event_) for descriptions (or encyclopedia entries) of particular subjects, and it's expected that multiple people will write articles about the exact same subjects, with either small variations or completely independent content. |
| 10 | 10 | ||
| 11 | Articles are identified by lowercase, normalized ascii `d` tags. | 11 | Articles are identified by lowercase, normalized ascii `d` tags. |
| 12 | 12 | ||
| @@ -26,21 +26,25 @@ Articles are identified by lowercase, normalized ascii `d` tags. | |||
| 26 | - Any non-letter character MUST be converted to a `-`. | 26 | - Any non-letter character MUST be converted to a `-`. |
| 27 | - All letters MUST be converted to lowercase. | 27 | - All letters MUST be converted to lowercase. |
| 28 | 28 | ||
| 29 | ### Content rules | 29 | ### Content |
| 30 | 30 | ||
| 31 | The content should be Asciidoc, following the same rules as of [NIP-23](23.md), although it takes some extra (optional) metadata tags: | 31 | The `content` should be Asciidoc with two extra functionalities: **wikilinks** and **nostr:...** links. |
| 32 | 32 | ||
| 33 | - `title`: for when the display title should be different from the `d` tag. | 33 | Unlike normal Asciidoc links `http://example.com[]` that link to external webpages, wikilinks `[[]]` link to other articles in the wiki. In this case, the wiki is the entirety of Nostr. Clicking on a wikilink should cause the client to ask relays for events with `d` tags equal to the target of that wikilink. |
| 34 | - `summary`: for display in lists. | ||
| 35 | - `a` and `e`: for referencing the original event a wiki article was forked from. | ||
| 36 | |||
| 37 | One extra functionality is added: **wikilinks**. Unlike normal Asciidoc links `[]()` that link to webpages, wikilinks `[[]]` link to other articles in the wiki. In this case, the wiki is the entirety of Nostr. Clicking on a wikilink should cause the client to ask relays for events with `d` tags equal to the target of that wikilink. | ||
| 38 | 34 | ||
| 39 | Wikilinks can take these two forms: | 35 | Wikilinks can take these two forms: |
| 40 | 36 | ||
| 41 | 1. `[[Target Page]]` -- in this case it will link to the page `target-page` (according to `d` tag normalization rules above) and be displayed as `Target Page`; | 37 | 1. `[[Target Page]]` -- in this case it will link to the page `target-page` (according to `d` tag normalization rules above) and be displayed as `Target Page`; |
| 42 | 2. `[[target page|see this]]` -- in this case it will link to the page `target-page`, but will be displayed as `see this`. | 38 | 2. `[[target page|see this]]` -- in this case it will link to the page `target-page`, but will be displayed as `see this`. |
| 43 | 39 | ||
| 40 | `nostr:...` links, as per [NIP-21](21.md), should link to profiles or arbitrary Nostr events. Although it is not recommended to link to specific versions of articles -- instead the _wikilink_ syntax should be preferred, since it should be left to the reader and their client to decide what version of any given article they want to read. | ||
| 41 | |||
| 42 | ### Optional extra tags | ||
| 43 | |||
| 44 | - `title`: for when the display title should be different from the `d` tag. | ||
| 45 | - `summary`: for display in lists. | ||
| 46 | - `a` and `e`: for referencing the original event a wiki article was forked from. | ||
| 47 | |||
| 44 | ### Merge Requests | 48 | ### Merge Requests |
| 45 | 49 | ||
| 46 | Event `kind:818` represents a request to merge from a forked article into the source. It is directed to a pubkey and references the original article and the modified event. | 50 | Event `kind:818` represents a request to merge from a forked article into the source. It is directed to a pubkey and references the original article and the modified event. |