add update event

101.md

@@ -1,123 +1,145 @@
-# NIP-101: Alias Exchange
+# NIP-101: Alias Key Exchange
 
 ## Abstract
 
-This NIP proposes the 'Alias Exchange' protocol, designed to facilitate the secure exchange of alias keys in private communication, thus protecting users' real npub keys. The protocol includes four kinds of events, each serving a specific function in the exchange process.
+This NIP proposes the 'Alias Exchange' protocol, designed to facilitate the secure exchange of alias keys in private communication. The protocol includes five kinds of events, each serving a specific function in the exchange process.
-
-## Motivation
-
-The Alias Exchange protocol enhances the security of NIP04 (private chat) by providing a means to protect real npub keys. By exchanging alias keys, users can communicate without revealing their real keys, reducing the risk of unauthorized access and potential data breaches. This protocol can be particularly useful in scenarios such as friend requests, acceptance of friend requests, rejection of friend requests, and removal of friends.
 
 
 ## Specification
 
 ### Kinds
 
-- **10100 - Request**: This event is initiated by the user who wants to start the alias key exchange. The initiator generates an alias public key derived from their own private key and the recipient's public key. The event sent is signed with the alias private key, and 'p' is the recipient's real public key.
+- **10100 - Request**: This event is initiated by the user who wants to start the alias key exchange.
 
-- **10101 - Accept**: This event represents the acceptance of the request for the alias key exchange. The recipient generates their own alias key using the same algorithm. The 'p' in this event is the initiator's alias public key.
+- **10101 - Accept**: This event represents the acceptance of the request for the alias key exchange.
 
-- **10102 - Reject**: This event signifies the rejection of the request for the alias key exchange. The rejection event is signed with the recipient's alias and sent to the initiator.
+- **10102 - Reject**: This event signifies the rejection of the request for the alias key exchange.
+
+- **10103 - Close**: This event is used to close the exchange session. 
+
+- **10104 - update**: This event is used to refresh the alias key.
 
-- **10103 - Remove**: This event is used to remove the alias. It is signed with the initiator's alias and sent to the recipient's alias public key.
 
 ### Implementation
 
-The protocol can be implemented following the steps below. Note that the content of the content field in this protocol is encrypted following the NIP04 protocol:
+The protocol can be implemented following the steps below:
 
-1. User A (the initiator) generates an alias key pair derived from their own private key and User B's (the recipient) public key.
+1. User A (the initiator) generates an alias key(random or derived).
 
-2. User A sends a 10100 kind event to User B, signed with their alias private key. The 'p' parameter is User B's real pubkey. The `encrypted_text` can be in json format.
+2. User A sends a 10100 kind event to User B, the 'p' parameter is User B's real pubkey.
 
 For example:
 
 ```json
 {
  "id": "event id",
- "pubkey": "A's alias public key for B",
+ "pubkey": "sender A",
  "kind": 10100,
  "tags": [
-    ["p", "B's real public key"],
+    ["p", <B's pubkey>, <A's alias pubkey for B>],
   ],
- "content": "<encrypted_text>?iv=<initialization_vector>",
+ "content": "<exchange details in json string format>",
- "sig": "<signature of the event id generated with A's alias private key>",
  ...other fields
 }
 ```
 
-In the content field, <encrypted_text> would be a JSON string:
+content example:
 
-```json
-{ 
-  "p":"A's real pubkey", 
-  "content":"your content",  
-  "sig":"<signature of the sha256 hash of the data: [eventCreateTime, p, content], generated with A's real private key>" 
-}
 ```
+{
+	"expiration": 1600000000,
+	"interval": 100, 
+	"r": "wss://relay.example.com"
+}
+
+```
+
+- **expiration**: Request expiration time
+- **interval**: Udpate alias key at every interval
+- **r**: Main relay for the exchange session 
 
 
 3. Upon receiving the request, User B can:
 
-   - Accept the request by generating their own alias key pair, sending a 10101 event to User A with their alias key, and using User A's alias pubkey as 'p' tag.
+   - Accept the request by generating his own alias key pair, sending a 10101 event to User A with his alias key.
 
    For example:
 
 ```json
 {
-  "pubkey": "B's alias pubkey for A",
+ "id": "event id",
+ "pubkey": "sender B",
  "kind": 10101,
  "tags": [
-    ["p", "A's alias pubkey for B"],
+    ["p", <A's pubkey>, <B's alias pubkey for A>],
+    ["e", "kind 10100 event id"],
   ],
-  "content": "<encrypted_text>?iv=<initialization_vector>",
+ "content": "",
  ...other fields
 }
 ```
    
-   - Reject the request by sending a 10102 event to User A, signed with their own alias.
+   - Reject the request by sending a 10102 event to User A.
 
 For example:
 
 ```json
 {
-  "pubkey": "B's alias pubkey for A",
+ "id": "event id",
+ "pubkey": "sender B",
  "kind": 10102,
  "tags": [
-    ["p", "A's alias pubkey for B"],
+    ["e", "kind 10100 event id"]
   ],
-  "content": "<encrypted_text>?iv=<initialization_vector>",
+ "content": "",
  ...other fields
 }
 ```
 
-4. If User A wants to remove the alias, they can send a 10103 event to User B, signed with their alias. The 'p' parameter is User B's alias public key.
+4. If User A wants to close the session, they can send a 10103 event to User B
 
 For example:
 
 ```json
 {
-  "pubkey": "A's alias pubkey for B",
+ "id": "event id",
+ "pubkey": "sender A",
  "kind": 10103,
  "tags": [
-    ["p", "B's alias pubkey for A"],
+    ["e", "kind 10100 event id"]
   ],
-  "content": "<encrypted_text>?iv=<initialization_vector>",
+ "content": "",
  ...other fields
 }
 ```
 
+5. Refresh the alias key
+
+```json
+{
+ "id": "event id",
+ "pubkey": "sender B",
+ "kind": 10104,
+ "tags": [
+    ["p", <A's pubkey>, <B's alias pubkey for A>],
+    ["e", "kind 10100 event id"],
+  ],
+ "content": "",
+ ...other fields
+}
+```
+
+
 A reference implementation for this protocol can be found [here](https://github.com/0xchat-app/nostr-dart/blob/main/lib/src/nips/nip_101.dart).
 
 
 ## Use Cases
 
-This protocol can be used in encrypted chat applications:
+This protocol can be used in secret chat applications:
 
-- 10100 (Request) is used to initiate a friend request, allowing users to start a conversation without revealing their real npub keys.
+- 10100 (Request) is used to initiate a secret chat request.
-- 10101 (Accept) is used to accept a friend request, confirming the establishment of secure chatting.
+- 10101 (Accept) is used to accept a secret request
-- 10102 (Reject) is used to reject a friend request, denying the establishment of chatting.
+- 10102 (Reject) is used to reject a secret request
-- 10103 (Remove) is used to remove a friend, effectively ending the secure chatting established.
+- 10103 (Close) is used to close a secret session
+- 10104 (Update) is used to update the secret shared key
 
-## Considerations
-
-While the Alias Exchange protocol enhances privacy, it does not guarantee absolute anonymity or security. It should be used as part of a broader suite of security measures to ensure overall secure communication.