nips/101.md
2023-09-02 22:16:14 +08:00

149 lines
3.2 KiB
Markdown

# 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. 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.
- **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.
- **10103 - Close**: This event is used to close the exchange session.
- **10104 - update**: This event is used to refresh the alias key.
### Implementation
The protocol can be implemented following the steps below:
1. User A (the initiator) generates an alias key(random or derived).
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": "sender A",
"kind": 10100,
"tags": [
["p", <B's pubkey>, <A's alias pubkey for B>],
],
"content": "<exchange details in json string format>",
...other fields
}
```
content example:
```
{
"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 his own alias key pair, sending a 10101 event to User A with his alias key.
For example:
```json
{
"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": "",
...other fields
}
```
- Reject the request by sending a 10102 event to User A.
For example:
```json
{
"id": "event id",
"pubkey": "sender B",
"kind": 10102,
"tags": [
["e", "kind 10100 event id"]
],
"content": "",
...other fields
}
```
4. If User A wants to close the session, they can send a 10103 event to User B
For example:
```json
{
"id": "event id",
"pubkey": "sender A",
"kind": 10103,
"tags": [
["e", "kind 10100 event id"]
],
"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).
## Note
The final events will be packaged and sent via [Gift Wrap](https://github.com/nostr-protocol/nips/blob/fd914c600fd590e6188534cd7555116da7855503/59.md), so there is no need to worry about information leakage.
## Use Cases
This protocol can be used in secret chat applications:
- 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