hcocoa on Nostr: 继续分析推荐relay（recommended relay ）的问题： ...
继续分析推荐relay（recommended relay ）的问题：
根据NIP-01，消息发送者的推荐relay，似乎不需要显式配置，而是由客户端隐式去访问，并且并不强制（语气用了could 和 MAY）。根据示例，似乎每次只能推荐一个relay，而且是跟着普通note一起发送，如果别人没有连接到作者写入的relay，其实是看不到的这个推荐relay的。
为了解决relay列表共享的问题，NIP-65提出了消息类型10002，用于消息发送者向外推荐relay列表。
根据该提案的建议，消息发送者仅将消息发送至少量relay（between 2 to 6 relays），同时广泛传播10002消息到大量relay（many more relays），让其他客户端了解到：（1）该作者write哪些relay，以便从其中获得消息更新；（2）该作者read哪些relay，以便在@该作者时提醒该作者。
目前NIP-65还在草案阶段，而且是可选的，希望后期有客户端可以实现，解决推荐relay的难题。 #Relaynology
仔细看了一下nostr的文档，这条也需要更正一下。事实应当是这样：
如果某个用户仅连接了自建relay，而你不知道他的自建relay地址，那么你即使你知道他的公钥，你也无法关注他。
除非：
1.你们曾经共同连接了某个relay
2.你曾经关注了他
3.他曾经推荐了他的自建relay地址
但是上面3中提到的推荐，因为没看到示例，还是不太清楚：
别人推荐的relay地址是否需要显式地加入自己的relay列表中？
还是客户端隐式地自动去访问？
后续会再仔细研究一下。如果有relay或者客户端开发者看到了，也希望可以解答一下🤝
#[0]
Published at
2023-02-09 03:31:23Event JSON
{
"id": "44c02d71ffc0b2c683e0bf85a09514ca7ecbfcc48216d969184670960725d5d8",
"pubkey": "7d9bcf523acc5b4b3ca3406cb62517b1b8a160cf07a164462bc587e8424f7b78",
"created_at": 1675913483,
"kind": 1,
"tags": [
[
"t",
"relaynology"
],
[
"e",
"d35c442576bb7086438b0280c26ba1d6ffecb03198afd4bbf46e87252d91edf7"
]
],
"content": "继续分析推荐relay（recommended relay ）的问题：\n\n根据NIP-01，消息发送者的推荐relay，似乎不需要显式配置，而是由客户端隐式去访问，并且并不强制（语气用了could 和 MAY）。根据示例，似乎每次只能推荐一个relay，而且是跟着普通note一起发送，如果别人没有连接到作者写入的relay，其实是看不到的这个推荐relay的。\n\n为了解决relay列表共享的问题，NIP-65提出了消息类型10002，用于消息发送者向外推荐relay列表。\n\n根据该提案的建议，消息发送者仅将消息发送至少量relay（between 2 to 6 relays），同时广泛传播10002消息到大量relay（many more relays），让其他客户端了解到：（1）该作者write哪些relay，以便从其中获得消息更新；（2）该作者read哪些relay，以便在@该作者时提醒该作者。\n\n目前NIP-65还在草案阶段，而且是可选的，希望后期有客户端可以实现，解决推荐relay的难题。 #Relaynology\n\n #[1]",
"sig": "ccfffde04ca01307b787b32088db546f85aaf67e5c91ab360d9e2698f0ae64995f6c897301ebf551dd15e25ef3977a425c5f8fbc4054778c9bbba661ebddcce0"
}
