nips/101.md

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:

{
 "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:

{
 "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:

{
 "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:

{
 "id": "event id",
 "pubkey": "sender A",
 "kind": 10103,
 "tags": [
    ["e", "kind 10100 event id"]
  ],
 "content": "",
 ...other fields
}

5. Refresh the alias key

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

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