哈哈，欢迎用英文的朋友讨论问题，不过既然你能用翻译看懂我们的讨论，我这边就不费劲翻译了哈。
你这个方法确实非常简单地解决了问题，用一个relay拥有的账号作为中转，替换A和B直接通信的记录。
不过还是留下了两条信息：
1. A给某人发了一条消息；
2. B收到了某人的消息。
虽然没法完全对应上，但是随着对话的持续，暴露两个人的讨论几乎是必然的。
Discussion
DM不就是这样实现的么？Relay现在不就是这么处理DM的么？
应该不是吧，不然你用pubkey登陆就看不到和谁聊天了。
The subtle difference is that, with the current implementation, only the message content is encrypted. The sender and receiver pubkeys are not. A DM (nostr event kind 4) looks like this
{
"content": "encrypted string",
"pubkey": "the pubkey of author",
"tags": [
["p", "the pubkey of receiver"]
// it's possible that you include multiple "p" tags so you can DM many people at the same time.
]
}
My proposal is to encrypt the whole original event A in to another event B of which the relay C is the receiver of B.
When C receives event B, C will decrypt it and find the original event A and forward the message.
Thanks for clarifying. Your proposal looks like CA architect. Correct me if I am wrong🙂
What is a CA architect? I need to read about it.
That's a fair point. But my assumption here is that, if enough people use this relay's pubkey as a mid point, the frequency will be so high that timestamp can't be used to trace the source. If a million people all send messages to C, and C sends back to this one million. The entropy is high enough.
是的，当用户量足够大的时候，确实大幅提升了追踪的成本，而且足够简单和成本低。