【忒修斯Relay之二：广播推荐Relay】

思考一个现实问题：

如果在未来的某个时点，我们目前连接relay逐个关站跑路了，或者由于某些原因无法连接，那么我们在切换到自建relay或者其他可用relay后，如何通知到现有的follower，使他们能够去新的relay继续找到我们呢？

nostr协议考虑到了这一点：

（1）NIP-01中定义的类型2事件（recommended_relay）

（2）NIP-65中定义的类型10002事件（relay list metadata）

其中：类型2每次可以推荐一个relay，适合自建relay的情形；类型10002则可以推荐包含多个relay的列表，并且分别标明作者如何使用这些relay（读、写、读写），便于客户端更加灵活地使用。

既然协议已经考虑到了这一点，但是不是就可以高枕无忧了呢？

抱着大胆假设小心求证的态度，我去github上查看了两个流行客户端的源代码，实际情况让我大跌眼镜。

1.Damus

在damus/Nostr/NostrKind.swift文件中，Damus定义了事件类型的枚举值，里面根本就不包含类型2和类型10002。也就是说，Damus目前压根就没打算实现relay推荐功能。

2.Snort.social

同样的，在src/Nostr/EventKind.ts中，Snort也定义了事件类型的枚举值，里面倒是提到了RecommendServer = 2。但是经过仓库的全文搜索，并没有代码引用这个，这表明Snort有考虑到NIP-01中的类型2推荐relay，但是暂时没有实现，更不要说NIP-65的类型10002了。

由此我们可以得出结论：现有的流行nostr客户端对于广播推荐relay地址并没有很好的支持。

因此在未来relay批量关站跑路或者被封禁的情况下，由于没有流行客户端实现类型2和类型10002事件，你需要另外的可靠信道把你新relay地址通知你的follower，可能会引起可用性问题。

#Relaynology