general improvents on the text

404.md

@@ -39,55 +39,51 @@ Because these platforms are centralized and closed-source, they can enforce "dig
 
 ---
 
-## How Nostr Can Handle This
+## Objective
 
-Nostr is decentralized, meaning that once an event is published, it exists permanently.
+Nostr is decentralized, meaning that once an event is published, it becomes a permanent record on the internet.
 
 As AI progresses, however, the content of an event alone becomes insufficient to prove authorship. Instead, people increasingly rely on cryptographic mechanisms to verify authorship.
 
 This NIP introduces a protocol for creating temporary events that are weakly tied to a public key, enabling ephemeral interactions without permanently binding them to the author's identity.
 
----
+We aim to produce events that are weakly tied to other public keys — events that are **probably** associated with that public key (e.g., Alice's) but cannot be **proven** to originate from it.
 
-## Objectives
+Additionally, we want to control the time window during which an event is likely from Alice. As time passes, the certainty of authorship decreases because more people had the opportunity to solve the challenge.
 
-We aim to produce events that are weakly tied to other public keys — events that are **probably** associated with that public key (e.g., Alice's) but cannot be **proven** to originate from her.
-
-Additionally, we want to control the time window during which an event is likely from Alice. As time passes, the certainty of authorship decreases.
 
 ---
 
 ## Implementation
 
-The author (Alice) proposes a challenge that is hard to solve but easy to verify.
+The author (Alice) will create a new key pair and use an arbitrary number of initial characters from the new `npub` as 
+a hint for the **challenge event** -- that is signed by Alice's main key.
 
-- Alice can arbitrarily determine the complexity of the challenge, making it simple for her to create but computationally intensive to solve.
-- Anyone can verify the solution but cannot prove that Alice was the solver.
+The challenge involves mining an `NSec` that generates an `Npub` beginning with the hint provided in Alice's challenge event.
 
-This **challenge event** is an event signed by Alice's public key and includes a hint to the solution.
+Whoever mines the `NSec` can publish an **ephemeral event** signed by the mined `NSec`. This event references the challenge event,
+enabling verification of the solved challenge.
+
+The **ephemeral event** public key is, therefore, completely detached from Alice's main key, making it impossible to 
+prove that Alice was the solver.
 
 ---
 
 ### Time Window
 
-To establish a chronological anchor for the challenge, the **challenge event** references a previous event. 
+To establish a chronological anchor for the challenge, Alice can use her timestamp when creating the challenge event.
+There is no really good reasons to lie about the timestamp.
+1) If she picks a timestamp in the future, she will give more time to others to solve the challenge, so
+people can impersonate her more easily.
+2) If she picks a timestamp in the past, clients will see that the **challenge event** is old and will know that 
+the **ephemeral events** that reference it are less likely to be from Alice.
 
 Alice controls the time window of the challenge in two ways:
-1. By selecting the reference event.
+1. By selecting the **challenge event** timestamp.
 2. By choosing the complexity of the challenge.
-
+3. [Optional] She also can use put a 'ref' tag in the **challenge event** to reference a previous event, so we can
+add a lower bound -- this is useful if you want to respond to a previous event.
 ---
-
-### Challenge and Ephemeral Events
-
-The challenge involves mining an `NSec` that generates an `Npub` beginning with the hint provided in Alice's challenge event. 
-
-- Whoever solves the challenge can publish an **ephemeral event** signed by the mined `NSec`.
-- The **ephemeral event** references the challenge event, enabling verification of the solved challenge.
-- The **ephemeral event** is signed by the mined `NSec`, detaching its authorship from Alice's public key.
-
----
-
 ### Client Behavior
 
 Clients can display a warning indicating that an event is ephemeral and uncertain. They can also show how much time has 
@@ -103,12 +99,6 @@ This feature can integrate with [NIP-44](40.md) to enhance the user experience.
 
 ---
 
-## Managed Ambiguity
-
-If the hint is too short, it becomes easy to prove implicitly that Alice solved the challenge. Conversely, if the hint is too long, anyone can solve it, defeating the challenge's purpose.
-
----
-
 ## Algorithm 
 
 (need review, copilot autocompleted a bit 🤡 ) 
@@ -119,7 +109,7 @@ If the hint is too short, it becomes easy to prove implicitly that Alice solved
    - `tags`: 
      - `["p", "<Alice's NPub>", "author"]`: Marks Alice as the author.
      - `["hint", "<first_n_digits_of_Random_NPub>"]`: Provides a hint for the solution.
-     - `["ref", "<previous_event_id>"]`: References a previous event.
+     - `["ref", "<previous_event_id>"]`: References a previous event. (Optional)
      - `["challenge"]`: Indicates this is a challenge event.
 3. Alice (or anyone) solves the challenge and publishes **ephemeral events** signed by the `Random NSec`, containing:
    - `pubkey`: The `Random NPub` if Alice solved it, or a mined `Npub` if someone else solved it.