Merge 1ba50a1cf6 into a1ca7a194b

29.md

@@ -30,8 +30,6 @@ When encountering just the `<host>` without the `'<group-id>`, clients MAY infer
 
 Events sent by users to groups (chat messages, text notes, moderation events etc) MUST have an `h` tag with the value set to the group _id_.
 
-`h` tags MAY include the group's name as the second argument. This allows `unmanaged` groups to be assigned human-readable names without relay support.
-
 ## Timeline references
 
 In order to not be used out of context, events sent to these groups may contain references to previous events seen from the same relay in the `previous` tag. The choice of which previous events to pick belongs to the clients. The references are to be made using the first 8 characters (4 bytes) of any event in the last 50 events seen by the user in the relay, excluding events by themselves. There can be any number of references (including zero), but it's recommended that clients include at least 3 and that relays enforce this.
@@ -242,3 +240,5 @@ A definition for `kind:10009` was included in [NIP-51](51.md) that allows client
 ### Using `unmanaged` relays
 
 To prevent event leakage, when using `unmanaged` relays, clients should include the [NIP-70](70.md) `-` tag, as just the `previous` tag won't be checked by other `unmanaged` relays.
+
+Groups MAY be named without relay support by adding a `name` to the corresponding tag in a user's `kind 10009` group list.

404.md

@@ -0,0 +1,126 @@
+# NIP-404: Deniable Events
+
+`draft` `optional`
+
+This NIP introduces a protocol for creating deniable events that are weakly tied to a public key, allowing ephemeral interactions without permanent attachment to the author's identity.
+
+---
+### TL;DR
+This is a form of key delegation with "expiration" based on proof of work difficulty.
+
+The main key generates a new key and uses the first chars of that new npub as a challenge. Anyone that solves that
+challenge and finds an npub that matches it can publish as the main key. Because it is proof of work, it will become 
+easier and easier to solve over time. Which creates some form of plausible deniability for the author.
+
+Clients have to warn users that the new key might not represent the author anymore based on the time it has passed and the proof of work required by the author.
+
+---
+
+## Rationale
+
+Nostr is a great protocol, 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.
+
+---
+
+## Objective
+
+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 deniable 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.
+
+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.
+
+
+---
+
+## Implementation
+
+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.
+
+The challenge involves mining an `NSec` that generates an `Npub` beginning with the hint provided in Alice's challenge event.
+
+Whoever mines the `NSec` can publish an **deniable event** signed by the mined `NSec`. This event references the challenge event,
+enabling verification of the solved challenge.
+
+The **deniable 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, 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 **deniable 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 **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.
+---
+### Client Behavior
+
+Clients can display a warning indicating that an event is deniable 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.
+
+---
+
+### Relays
+
+*TODO*
+
+---
+
+## 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. (Optional)
+     - `["challenge"]`: Indicates this is a challenge event.
+3. Alice (or anyone) solves the challenge and publishes **deniable 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.
+     - `["deniable"]`: Indicates this is an deniable 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.

51.md

@@ -29,7 +29,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
 | Public chats      | 10005 | [NIP-28](28.md) chat channels the user is in                | `"e"` (kind:40 channel definitions)                                               |
 | Blocked relays    | 10006 | relays clients should never connect to                      | `"relay"` (relay URLs)                                                            |
 | Search relays     | 10007 | relays clients should use when performing search queries    | `"relay"` (relay URLs)                                                            |
-| Simple groups     | 10009 | [NIP-29](29.md) groups the user is in                       | `"group"` ([NIP-29](29.md) group id + relay URL), `"r"` for each relay in use     |
+| Simple groups     | 10009 | [NIP-29](29.md) groups the user is in                       | `"group"` ([NIP-29](29.md) group id + relay URL + optional group name), `"r"` for each relay in use     |
 | Interests         | 10015 | topics a user may be interested in and pointers             | `"t"` (hashtags) and `"a"` (kind:30015 interest set)                              |
 | Emojis            | 10030 | user preferred emojis and pointers to emoji sets            | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set)                  |
 | DM relays         | 10050 | Where to receive [NIP-17](17.md) direct messages            | `"relay"` (see [NIP-17](17.md))                                                   |