From f1b5e32bcf3943632928e6a6fd0d954f046b7a05 Mon Sep 17 00:00:00 2001
From: arthurfranca <arthur.a.franca@gmail.com>
Date: Thu, 15 Feb 2024 08:53:30 -0300
Subject: [PATCH] Remove custom serialization and add more explanation

---
 00.md | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/00.md b/00.md
index 1c6edcaf..91b8f2ba 100644
--- a/00.md
+++ b/00.md
@@ -17,13 +17,18 @@ must be published or updated with a `full_event` tag pointing to a
 It's data should be set to a warning that the event is private or to a preview version of the full event, in case the
 goal is to tease an user to pay for content, for example.
 
-For example, a `kind:1` event could have it's `.content` set to "You don't have access to this event." to be showed
-to users that don't have acces to the event or that are using a client that doesn't support this NIP. On the other hand,
-if the goal is to convince an user to pay for the full event, the `.content` could be set to a text excerpt like the following:
-"This is the first sentence of the full text. This text is trimmed to 5% of the character count of the full text..."
+For example, a `kind:1` event could have it's `.content` set to "This event is private." to be showed
+to users that don't have acces to the event or that are using clients that don't support this NIP. On the other hand,
+if the goal is to convince viewing users to pay for the full event, the `.content` could be set to a text excerpt like the following:
+"This is the first sentence of the full text. This text is trimmed to 5% of the character count of the full text... Subscribe
+to read the full text".
 
 Taking the `kind:1063` metadata event of an image as an example, it could had set its `url` tag to a blurred version of the image
-or simply use the `.content` (that according to NIP-94 means "caption") set to "You don't have access to this event".
+and/or use the `.content` (that according to NIP-94 means "caption") set to "This event is private".
+
+How the public event data will be set is entirely up to the client offering
+the feature that requires event access control. Such feature could be
+a "Publish only to Close Friends" or "Publish to Paying Subscribers", for example.
 
 Example:
 
@@ -45,20 +50,23 @@ Example:
 A "Full Event" is of `kind:40042`. It has [NIP-42](42.md) `A` tags the author
 can update at will with the pubkeys allowed to access it.
 
-It uses the custom NIP-42 event serialization for events that require `AUTH`.
-
 The `.content` and other tags aren't fixed. The structure depends on the
 kind of the public event it is protecting. For example, if it is
 protecting a `kind:30023` event, it should have the structure defined on [NIP-23](23.md).
 
-Example:
+An interesting side effect of this being an event separate from the public one
+is that it doesn't need to be owned by the public event author. This way
+an always online bot or DVM can update the `A` tag list in response to
+a detected payment, for example.
+
+Example of a `kind:40042` event using a `kind:1063` event structure:
 
 ```json
 {
   "kind": 40042,
   "pubkey": "<author_pubkey>",
   "tags": [
-    ["d", "<random>"],
+    ["d", "<random>"], // act as parameterized replaceable event
     ["A", "<author_pubkey>"], // important to keep author access right
     ["A", "<buyer_1_pubkey>"],
     ["A", "<buyer_2_pubkey>"],