nips/101.md

# NIP-101: Alias 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.


## 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.

- **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.

- **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.

- **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:

1. User A (the initiator) generates an alias key pair derived from their own private key and User B's (the recipient) public key.

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.

For example:

```json
{
 "id": "event id",
 "pubkey": "A's alias public key for B",
 "kind": 10100,
 "tags": [
    ["p", "B's real public key"],
  ],
 "content": "<encrypted_text>?iv=<initialization_vector>",
 "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:

```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>" 
}
```


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.

   For example:

```json
{
  "pubkey": "B's alias pubkey for A",
  "kind": 10101,
  "tags": [
    ["p", "A's alias pubkey for B"],
  ],
  "content": "<encrypted_text>?iv=<initialization_vector>",
  ...other fields
}
```
   
   - Reject the request by sending a 10102 event to User A, signed with their own alias.

      For example:

```json
{
  "pubkey": "B's alias pubkey for A",
  "kind": 10102,
  "tags": [
    ["p", "A's alias pubkey for B"],
  ],
  "content": "<encrypted_text>?iv=<initialization_vector>",
  ...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:

```json
{
  "pubkey": "A's alias pubkey for B",
  "kind": 10103,
  "tags": [
    ["p", "B's alias pubkey for A"],
  ],
  "content": "<encrypted_text>?iv=<initialization_vector>",
  ...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:

- 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.

## 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.