mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-22 08:25:53 -05:00
add update event
This commit is contained in:
water783
parent
62b7389963
commit
fe1ef65b8b
134
101.md
134
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.
|
||||
|
||||
## 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.
|
||||
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.
|
||||
|
||||
|
||||
## 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>",
|
||||
"sig": "<signature of the event id generated with A's alias private key>",
|
||||
"content": "<exchange details in json string format>",
|
||||
...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",
|
||||
"kind": 10101,
|
||||
"tags": [
|
||||
["p", "A's alias pubkey for B"],
|
||||
"id": "event id",
|
||||
"pubkey": "sender B",
|
||||
"kind": 10101,
|
||||
"tags": [
|
||||
["p", <A's pubkey>, <B's alias pubkey for A>],
|
||||
["e", "kind 10100 event id"],
|
||||
],
|
||||
"content": "<encrypted_text>?iv=<initialization_vector>",
|
||||
...other fields
|
||||
"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:
|
||||
For example:
|
||||
|
||||
```json
|
||||
{
|
||||
"pubkey": "B's alias pubkey for A",
|
||||
"kind": 10102,
|
||||
"tags": [
|
||||
["p", "A's alias pubkey for B"],
|
||||
"id": "event id",
|
||||
"pubkey": "sender B",
|
||||
"kind": 10102,
|
||||
"tags": [
|
||||
["e", "kind 10100 event id"]
|
||||
],
|
||||
"content": "<encrypted_text>?iv=<initialization_vector>",
|
||||
...other fields
|
||||
"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.
|
||||
|
||||
For example:
|
||||
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",
|
||||
"kind": 10103,
|
||||
"tags": [
|
||||
["p", "B's alias pubkey for A"],
|
||||
"id": "event id",
|
||||
"pubkey": "sender A",
|
||||
"kind": 10103,
|
||||
"tags": [
|
||||
["e", "kind 10100 event id"]
|
||||
],
|
||||
"content": "<encrypted_text>?iv=<initialization_vector>",
|
||||
...other fields
|
||||
"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.
|
||||
- 10101 (Accept) is used to accept a friend request, confirming the establishment of secure chatting.
|
||||
- 10102 (Reject) is used to reject a friend request, denying the establishment of chatting.
|
||||
- 10103 (Remove) is used to remove a friend, effectively ending the secure chatting established.
|
||||
- 10100 (Request) is used to initiate a secret chat request.
|
||||
- 10101 (Accept) is used to accept a secret request
|
||||
- 10102 (Reject) is used to reject a secret request
|
||||
- 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.
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user