btcdage on Nostr: nostr协议安全私聊自动化软件详细设计 自动安全私聊方案设计： ...

nostr协议安全私聊自动化软件详细设计

自动安全私聊方案设计：

用户用公开的账户A，想和公开的账户B进行安全私聊。

1、用户使用 A_nsec1登录客户端A，点击用户B的B_npub1的资料界面。

2、点击进入安全私聊界面。
a、客户端A自动生成一个 公钥私钥对（C1_nsec1/C1_pub1）。
b、客户端A将安全私聊请求以正常私聊的协议方式发送到relay，内容包括 C1_nsec1/C1_pub1。客户端B收到私聊请求和C1信息。
c、客户端B，开始监听C1的私聊接收事件。
（这个过程中，在relay侧暴露一次 A --->B 的私聊动作，单因内容加密，C1_nsec1/C1_pub1是第三方保密的）。

3、A发送安全私聊信息比如“你在吗？”。
a、客户端A自动生成一个公钥私钥对（C2_nsec1/C2_npub1），和A的昵称、发送的信息进行拼接，比如“{s:C2_nsec1,p:C2_npub1,n:"btcdage",c:"你在吗？"”，用约定好的C1_nsec1签名后，通过普通私聊协议发送给C1。然后客户端A开始监听C2的私聊事件。

b、客户端B收到C1的私聊事件，用C1_npub1解密后，进行显示：

btcdage:你在吗？

4、客户端B回复“我在。”
a、客户端B生成一个新的公钥私钥对（C3_nsec1/C3_npub1），和使用B的昵称、回复的信息进行拼接，比如“{s:C3_nsec1,p:C3_npub1,n:"satoshi",c:"我在。"”,用C2_nsec1签名后，通过普通私聊协议发送给C2。然后客户端B开始监听C3的私聊事件。
b、客户端A收到C2的私聊事件，用C2_npub1解密后，进行显示：

satoshi:我在。

5、A再次发送安全私聊信息比如“吃饭了吗？”。
a、客户端A自动生成一个公钥私钥对（C4_nsec1/C4_npub1），和A的昵称、发送的信息进行拼接，比如“{s:C4_nsec1,p:C4_npub1,n:"btcdage",c:"吃饭了吗？"”，用约定好的C3_nsec1签名后，通过普通私聊协议发送给C3。然后客户端A开始监听C4的私聊事件。

b、客户端B收到C3的私聊事件，用C3_npub1解密后，进行显示：

btcdage: 吃饭了吗？

6、客户端B回复“吃过了。”
a、客户端B生成一个新的公钥私钥对（C5_nsec1/C5_npub1），和使用B的昵称、回复的信息进行拼接，比如“{s:C5_nsec1,p:C5_npub1,n:"satoshi",c:"吃过了。"”,用C4_nsec1签名后，通过普通私聊协议发送给C4。然后客户端B开始监听C5的私聊事件。
b、客户端A收到C4的私聊事件，用C4_npub1解密后，进行显示：

satoshi:吃过了。

如上所示，客户端A和客户端B通过一次公钥A---》公钥B的私聊消息传递之后，就进入了C1-C2-C3-C4-Cn...无限临时账户的信息交流。每个临时账户的聊天记录里只有一个单独的语句，不构成对话，无法挖掘任何信息。

一旦退出软件或者点击“停止安全聊天”，则客户端停止监听Cn的私聊事件。再次私聊需要再次从第一步开始。

聊天记录只在本地客户端的缓存显示，一旦清除缓存或者客户端不保留缓存，则不可能还原。
======================
基于nostr协议安全私聊的一点想法，聊做抛砖引玉。