nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-23 08:55:52 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

update text

Browse Source
This commit is contained in:
0xchatTeam 2023-05-14 22:44:37 +08:00
parent 85f2b2f833
commit 0b4032c3e7
1 changed files with 28 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
101.md
View File

@ -13,13 +13,13 @@ The Alias Exchange protocol enhances the security of NIP04 (private chat) by pro
### Kinds ### 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. - **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 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. - **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 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. - **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 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. - **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 ### Implementation
@ -27,28 +27,31 @@ The protocol can be implemented following the steps below. Note that the content
1. User A (the initiator) generates an alias key pair derived from their own private key and User B's (the recipient) public key. 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: 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.
```json
{
"p":"A's real pubkey",
"content":"your content",
"sig":"<64-bytes hex of the signature of the event id, signed by A's real private key>"
}
```
For example: For example:
```json ```json
{ {
"pubkey": "A's alias pubkey for B", "id": "event id",
"kind": 10100, "pubkey": "A's alias public key for B",
"tags": [ "kind": 10100,
["p", "B's real pubkey"], "tags": [
["p", "B's real public key"],
], ],
"content": "<encrypted_text>?iv=<initialization_vector>", "content": "<encrypted_text>?iv=<initialization_vector>",
...other fields "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 event id, generated with A's real private key>"
} }
``` ```
@ -110,11 +113,11 @@ A reference implementation for this protocol can be found [here](https://github.
This protocol can be used in encrypted chat applications: 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. - 10100 (Request) 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. - 10101 (Accept) 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. - 10102 (Reject) 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. - 10103 (Remove) is used to remove a friend, effectively ending the secure chatting established.
## Considerations ## 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. 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.