nips/404.md

# NIP-404: Ephemeral Events

`draft` `optional`

This NIP introduces a protocol for creating ephemeral events that are weakly tied to a public key, allowing ephemeral interactions without permanent attachment to the author's identity.

---

## Rationale

Nostr is a great platform, but the fact that each published event is eternally tied to a public key (`npub`) presents a dilemma for users:

- When you post something under your public key:
  - You are permanently linked to that event, leaving no room for privacy or a "right to be forgotten."
  - You cannot freely make mistakes or change your mind later, especially when you're young.
  - Posting impulsively—when drunk or not thinking clearly—becomes a permanent record.
  - You are essentially bound to your mistakes forever.
- If you regret posting something, you can claim that you were hacked. However, this undermines trust in your public key, effectively destroying your digital identity.
- Using a new public key for each event sacrifices the ability to maintain a long-term identity.

---

## How Centralized Social Media Platforms Handle This

- **Temporary Stories**: Platforms like Instagram, Snapchat, and Facebook allow users to post stories that disappear after a set period.
- **Temporary Messages**: Messaging platforms like Signal, WhatsApp, and Telegram enable users to send messages that disappear after being read.

Because these platforms are centralized and closed-source, they can enforce "digital scarcity" on content, ensuring it disappears over time.

---

## How Nostr Can Handle This

Nostr is decentralized, meaning that once an event is published, it exists permanently.

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.

---

## Objectives

We aim to produce events that are weakly tied to a public key—events that are **probably** associated with a 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.

- 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.

This **challenge event** is an event signed by Alice's public key and includes a hint to the solution.

---

### Time Window

To establish a chronological anchor for the challenge, the **challenge event** references a previous event. 

Alice controls the time window of the challenge in two ways:
1. By selecting the reference event.
2. By choosing the complexity of the challenge.

---

### 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 
passed since the challenge was published. Clients may choose to stop displaying events that are too old or uncertain.

This feature can integrate with [NIP-44](40.md) to enhance the user experience.

---

### Relays

*TODO*

---

## 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 🤡 ) 
1. Alice generates a random key pair: (`Random NPub`, `Random NSec`).
2. Alice publishes a **challenge event** signed by her primary key, containing the following fields:
   - `pubkey`: `Random NPub`
   - `content`: The challenge.
   - `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.
     - `["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.
   - `content`: The usual event content.
   - `tags`: 
     - `["p", "<Alice's NPub>", "author"]`: Tags Alice as the author.
     - `["challenge", "<challenge_event_id>"]`: Links to the challenge event.
     - `["ephemeral"]`: Indicates this is an ephemeral event.

---

## Security Considerations

- The `hint` length can be adjusted to balance the ease of mining by powerful actors with the desired temporary nature of the event.
- Over time, the likelihood that others can solve the challenge increases, reducing confidence in Alice's authorship.
- Shortly after receiving the event, Bob can be reasonably confident it came from Alice. However, this confidence diminishes with time.