declare `nref` on NIP-33. remove need for NIP-01 bridge event.

1 files changed, 5 insertions, 11 deletions

diff --git a/23.md b/23.md
index b8b8698..1559788 100644
--- a/23.md
+++ b/23.md
@@ -24,23 +24,17 @@ These articles are meant to be editable, so they should make use of the replacea
 
 ### 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.
+The article may be linked to using the NIP-19 `nref` code along with the `"f"` tag (see NIP-33 and NIP-19).
 
 ### 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]`).
+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](nref1...)`) 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:` 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 `nostr:nref1...` 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.
+The same principles can be applied to `nevent1...`, `note1...`, `nprofile1...` or `npub1...`.
 
 ## Example of an event
 
@@ -67,7 +61,7 @@ Derived event:
     ["t", "lorem"],
     ["t", "ipsum"],
     ["e", "b3e392b11f5d4f28321cedd09303a748acfd0487aea5a7450b3481c60b6e4f87", "wss://relay.example.com"],
-    ["e", "a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919", "wss://relay.nostr.org"]
+    ["f", "a695f6b60119d9521934a691347d9f78e8770b56da16bb255ee286ddf9fda919:ipsum", "wss://relay.nostr.org"]
   ],
   "pubkey": "...",
   "id": "..."