NIP-23: long-form content.

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
+  - `nref`: a nostr parameterized replaceable event coordinate (NIP-33)
 
 These possible standardized `TLV` types are indicated here:
 
@@ -42,11 +43,15 @@ 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 `nref`, it is the identifier (the `"d"` tag) of the event being referenced
   - for `nprofile`, `nevent` and `nrelay` this may be included only once.
 - `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 `nref`, 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
-  - not applicable to `nrelay`.
+- `2`: `author`
+  - for `nref`, the 32 bytes of the pubkey of the event
+
+
 ## Examples
 
 - `npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6` should decode into the public key hex `3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d` and vice-versa

23.md

@@ -0,0 +1,75 @@
+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, including YAML front-matter for other metadata that may be necessary.
+
+### Metadata
+
+This NIP defines only `title` as the metadata. For the date of publication the event `.created_at` field should be used, and for "tags"/"hashtags" (i.e. topics about which the event might be of relevance) the `"t"` event tag should be used, as in NIP-12.
+
+### 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 `nref` code, which should contain both the public key of the author and the article identifier (the `"d"` tag) and some relays. With that information it is possible to locate the article.
+
+### References
+
+Writing clients should implement support for parsing pasted NIP-19 `nref` 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](nref...)`) then they should be replaced with just the tag number directly (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:` 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.
+
+### `kind:1` interface
+
+In case there is the desire for users or clients to share the written article on their "social" clients, a `kind:1` event must be used.
+
+Since "social" clients aren't expected to understand this NIP, these notes should contain a URL like `nostr:nref1...` specifying the `nref1` code for the article, such that it can be rendered clickable and other users can use a different client than their "social" to read the article -- and also if their client handles both kinds of posts, their client may recognize the URL and handle it internally.
+
+For clients that want to implement the ability for users to comment on these articles. `kind:1` notes should be used as the comments. They must be made in reply to another `kind:1` as above, such that other people on "social" clients can see the comments and get the context from the note above and load the article being commented on if they so desire.
+
+## Example of an event
+
+Article text:
+
+```markdown
+title: Lorem Ipsum
+---
+
+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.
+
+Read more at #[3].
+```
+
+Derived event:
+
+```json
+{
+  "kind": 30023,
+  "created_at": 1000000000,
+  "title": "Lorem Ipsum\\n---\\n\\nLorem [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"],
+    ["t", "lorem"],
+    ["t", "ipsum"],
+    ["e", "b3e392b11f5d4f28321cedd09303a748acfd0487aea5a7450b3481c60b6e4f87", "wss://relay.example.com"],
+    ["e", "a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919", "wss://relay.nostr.org"]
+  ],
+  "pubkey": "...",
+  "id": "..."
+}
+```

README.md

@@ -41,6 +41,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 | 3           | Contacts                    | [2](02.md)             |
 | 4           | Encrypted Direct Messages   | [4](04.md)             |
 | 5           | Event Deletion              | [9](09.md)             |
+| 30023       | Long-form Content           | [23](23.md)            |
 | 7           | Reaction                    | [25](25.md)            |
 | 40          | Channel Creation            | [28](28.md)            |
 | 41          | Channel Metadata            | [28](28.md)            |