逻辑应该是这样：先去客户端内置的relay servers查一遍，没有用户当前使用的relay list，再广播当前客户端内置的relay list到这些server，如果客户端添加了relay server，也是先去查一遍，如果已有relay list，把当前的relay list加上去，如果没有，则把当前的relay list广播到新添加的relay server。
Discussion
只要第一次初始化时客户端内置relays没有你之前正在用的。它们存储的元数据/联系人这些信息都是旧的或者不存在，这时候广播就是旧数据覆盖新数据或者清空。
用户第一次用某个客户端，这个客户端里没有任何用户历史数据，它只有默认的relay servers list。此时，用kind 3来广播用户所用的relays，就是这些默认的relays，广播到哪里呢，就是这些默认的relay上。
此时用户所用的relay list，就是有两种：
1、用户以前的relay list，在以前的relay servers上
2、用户在新客户端所用的relay list，在这个list里的relay servers上。
两种完全不冲突。
如果用户手动添加以前使用的relay server，那么客户端应该先去以前这个relay server上查询用户的relay list，然后跟当前的relay list合并，最后再广播到默认relay list servers+用户添加的relay server上。【本质上就是个查询不同数据库，合并信息，并同步到这些数据库里】
所以我上面回复的逻辑，就是说，不管客户端使用哪些relay servers，都应该先去查kind 3，有则合并。
抱歉我搞混淆了，kind 3--> kind 10002
晕头转向的一天……就是kind 3，content里有用户的relay list
是什么kind并不重要，重点是第一次广播后元数据/联系人就都被覆盖了，后面即使你再加回来relay，上面数据也变成旧的了，也还是会被覆盖，除非能够指明新加回来的relay是最高优先级。
所以说，重点是，在第一次广播前，要先去查历史，别啥也不查就去广播数据。
客户端默认relays如果不是正在使用的话，查了也是旧数据或者没有，不广播又该什么时候广播？客户端并不知道用户是否会加回自己的relays。
你说的情况我理解，我在另一个帖子上写了，没有妥善解决前，登入客户端第一步先去添加relay。
查了旧数据/没有，然后再去广播，就能有效避免历史信息被覆盖。
你说的方法：用户登录新客户端后，手工添加原来使用的relay
这种方式，在这个不分青红皂白就广播的客户端上，恰好可以清空用户历史数据。
没有数据则啥也不做，不要广播relay列表，relay列表数据只在用户手动post时才进行广播。就解决了这个问题。
有意思，尝试理解一下你的逻辑。
客户端初始化第一步都是先请求内置relay的元数据和联系人，显示给用户，如果这些内置relay比如都是一个月前用过的，客户端得到的就是旧数据，但用户需要今天的最新数据，接下来该怎么处理？
没有则啥也不做，因为反正用户也没post过relay列表，啥也不做就用默认的客户端relay就行了，直到用户post
所以别删damus默认的relay😂
清空relay列表的确没有信息了（尤其有几个关键的公共relay），但再添加回来，信息立马就恢复了。难道这种操作还有丢失元信息的风险？🤔