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 Exchange: 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 Exchange: 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 Exchange: 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 Alias: 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:

User A (the initiator) generates an alias key pair derived from their own private key and User B's (the recipient) public key.
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: {"p":"A's real pubkey", "content":"your content"}.

For example:

{
  "pubkey": "A's alias pubkey for B",
  "kind": 10100,
  "tags": [
    ["p", "B's real pubkey"],
  ],
  "content": "<encrypted_text>?iv=<initialization_vector>",
  ...other fields
}

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:

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

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

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:

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

Use Cases

This protocol can be used in encrypted chat applications:

10100 (Request Exchange) is used to initiate a friend request, allowing users to start a conversation without revealing their real npub keys.
10101 (Accept Exchange) is used to accept a friend request, confirming the establishment of secure chatting.
10102 (Reject Exchange) is used to reject a friend request, denying the establishment of chatting.
10103 (Remove Alias) is used to remove a friend, effectively ending the secure chatting established.

Considerations

While the Alias Key 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.

4.4 KiB Raw Blame History