# 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