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

2 files changed, 21 insertions, 13 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": "..."
diff --git a/33.md b/33.md
index 6b05bd0..314cc83 100644
--- a/33.md
+++ b/33.md
@@ -12,10 +12,10 @@ Implementation
 --------------
 The value of a tag is defined as the first parameter of a tag after the tag name.
 
-A *parameterized replaceable event* is defined as an event with a kind `30000 <= n < 40000`.  
+A *parameterized replaceable event* is defined as an event with a kind `30000 <= n < 40000`.
 Upon a parameterized replaceable event with a newer timestamp than the currently known latest
 replaceable event with the same kind and first `d` tag value being received, the old event
-SHOULD be discarded and replaced with the newer event.  
+SHOULD be discarded and replaced with the newer event.
 A missing or a `d` tag with no value should be interpreted equivalent to a `d` tag with the
 value as an empty string. Events from the same author with any of the following `tags`
 replace each other:
@@ -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 `nref` 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 `nref` code is the tag `"f"`, comprised of `["f", "<pubkey>:<d-identifier>", "<relay url>"]`.
+
 Client Behavior
 ---------------