Merge pull request #220 from nostr-protocol/longform

19.md

@@ -35,6 +35,7 @@ These are the possible bech32 prefixes with `TLV`:
   - `nprofile`: a nostr profile
   - `nevent`: a nostr event
   - `nrelay`: a nostr relay
+  - `naddr`: a nostr parameterized replaceable event coordinate (NIP-33)
 
 These possible standardized `TLV` types are indicated here:
 
@@ -42,11 +43,17 @@ These possible standardized `TLV` types are indicated here:
   - depends on the bech32 prefix:
     - for `nprofile` it will be the 32 bytes of the profile public key
     - for `nevent` it will be the 32 bytes of the event id
-    - for `nrelay`, this is the relay URL.
+    - for `nrelay`, this is the relay URL
-  - for `nprofile`, `nevent` and `nrelay` this may be included only once.
+    - for `naddr`, it is the identifier (the `"d"` tag) of the event being referenced
 - `1`: `relay`
-  - A relay in which the entity (profile or event) is more likely to be found, encoded as UTF-8. This may be included multiple times.
+  - for `nprofile`, `nevent` and `naddr`, a relay in which the entity (profile or event) is more likely to be found, encoded as ascii
-  - not applicable to `nrelay`.
+  - this may be included multiple times
+- `2`: `author`
+  - for `naddr`, the 32 bytes of the pubkey of the event
+- `3`: `kind`
+  - for `naddr`, the 32-bit unsigned integer of the kind, big-endian
+
+
 ## Examples
 
 - `npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6` should decode into the public key hex `3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d` and vice-versa

23.md

@@ -0,0 +1,64 @@
+NIP-23
+======
+
+Long-form Content
+-----------------
+
+`draft` `optional` `author:fiatjaf`
+
+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".
+
+"Social" clients that deal primarily with `kind:1` notes should not be expected to implement this NIP.
+
+### Format
+
+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.
+
+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:
+
+- `"title"`, for the article title
+- `"image"`, for a URL pointing to an image to be shown along with the title
+- `"summary"`, for the article summary
+- `"published_at"`, for the timestamp in unix seconds (stringified) of the first time the article was published
+
+### 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.
+
+### Linking
+
+The article may be linked to using the NIP-19 `naddr` code along with the `"a"` tag (see NIP-33 and NIP-19).
+
+### 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]`).
+
+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.
+
+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.
+
+The same principles can be applied to `nevent1...`, `note1...`, `nprofile1...` or `npub1...`.
+
+## Example Event
+
+```json
+{
+  "kind": 30023,
+  "created_at": 1675642635,
+  "content": "Lorem [ipsum][4] dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.\n\nRead more at #[3].",
+  "tags": [
+    ["d", "lorem-ipsum"],
+    ["title", "Lorem Ipsum"],
+    ["published_at", "1296962229"],
+    ["t", "placeholder"],
+    ["e", "b3e392b11f5d4f28321cedd09303a748acfd0487aea5a7450b3481c60b6e4f87", "wss://relay.example.com"],
+    ["a", "30023:a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919:ipsum", "wss://relay.nostr.org"]
+  ],
+  "pubkey": "...",
+  "id": "..."
+}
+```

33.md

@@ -30,6 +30,20 @@ replace each other:
 
 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.
 
+Referencing and tagging
+-----------------------
+
+Normally (as per NIP-01, NIP-12) 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
+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>"]`.
+
 Client Behavior
 ---------------
 

README.md

@@ -35,7 +35,6 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 - [NIP-65: Relay List Metadata](65.md)
 
 ## Event Kinds
-
 | kind          | description                      | NIP                     |
 | ------------- | -------------------------------- | ----------------------- |
 | 0             | Metadata                         | [1](01.md), [5](05.md)  |
@@ -56,6 +55,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 | 9735          | Zap                              | [57](57.md)             |
 | 10002         | Relay List Metadata              | [65](65.md)             |
 | 22242         | Client Authentication            | [42](42.md)             |
+| 30023         | Long-form Content                | [23](23.md)             |
 | 1000-9999     | Regular Events                   | [16](16.md)             |
 | 10000-19999   | Replaceable Events               | [16](16.md)             |
 | 20000-29999   | Ephemeral Events                 | [16](16.md)             |
@@ -92,6 +92,7 @@ When experimenting with kinds, keep in mind the classification introduced by [NI
 | ---------- | ----------------------- | ----------------- | ------------------------ |
 | e          | event id (hex)          | relay URL, marker | [1](01.md), [10](10.md)  |
 | p          | pubkey (hex)            | relay URL         | [1](01.md)               |
+| a          | coordinates to an event | relay URL         | [33](33.md), [23](23.md) |
 | r          | a reference (URL, etc)  |                   | [12](12.md)              |
 | t          | hashtag                 |                   | [12](12.md)              |
 | g          | geohash                 |                   | [12](12.md)              |