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
根据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
quoting nevent1q…yhky仔细看了一下nostr的文档，这条也需要更正一下。事实应当是这样：
如果某个用户仅连接了自建relay，而你不知道他的自建relay地址，那么你即使你知道他的公钥，你也无法关注他。
除非：
1.你们曾经共同连接了某个relay
2.你曾经关注了他
3.他曾经推荐了他的自建relay地址
但是上面3中提到的推荐，因为没看到示例，还是不太清楚：
别人推荐的relay地址是否需要显式地加入自己的relay列表中？
还是客户端隐式地自动去访问？
后续会再仔细研究一下。如果有relay或者客户端开发者看到了，也希望可以解答一下🤝
#[0]