#[0]
但我其实更期望nostr的协议简洁而够用。然后大家在其上自由发挥做自己的扩展。
就像我们不能用分叉的方式来让比特币支持闪电网络。
就像现在大家热衷讨论的用nostr现有的手段，通过临时账号等手段，实现隐藏元信息的私聊。
一旦标准协议把某个事情的做法限死了，就不好玩了。
Discussion
One approach is to: assuming A and B want to talk. A can first encrypt the originial message M with A's private key and B's pubkey, the result is E(A,B,M). Then further encrypt E(AB,M) to E(AC,E(AB,M)) and send to C, which is a normal nostr pubkey owned by the relay. The relay will decrypt the message and find the receiver and forward to B. C is not capable of seeing the message.
Of course, C, the relay will know that A and B are talking. But the public can't trace this information.
The implementation is very easy. I will implement this in blowater.deno.dev if any relay is willing to implement it.
哈哈，欢迎用英文的朋友讨论问题，不过既然你能用翻译看懂我们的讨论，我这边就不费劲翻译了哈。
你这个方法确实非常简单地解决了问题，用一个relay拥有的账号作为中转，替换A和B直接通信的记录。
不过还是留下了两条信息：
1. A给某人发了一条消息；
2. B收到了某人的消息。
虽然没法完全对应上，但是随着对话的持续，暴露两个人的讨论几乎是必然的。
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.
是的，当用户量足够大的时候，确实大幅提升了追踪的成本，而且足够简单和成本低。