行了不用回复了，我不知道应该用哪种语言才能跟你有效沟通，就此打住了。
你可真是个人才，建议你去制定一套协议，一定会超过Nostr让更多人喜欢，大家围绕你的协议开发出一个生态来，明天多西就来投资，从此走上人生巅峰。
这不就是协议的含义吗？
协议不就是规定了一套服务端怎么服务的规则么
然后客户端按规则跟服务端互动呀……客户端不守规则，难道要所有的服务端去迁就客户端？
发哪儿前查哪儿。还看不懂我也没辙。请中文好的来解释吧。
它不需要满世界查询，只需要查即将要发的relay server里有什么历史就可以了。看懂了不？
你看到具体的kind3里面是什么了吗？光背书所以你才搞不懂。
Nostr的核心思想是服务端做尽可能少的事，这样可以用很低廉的硬件资源就建立服务，从而让服务器遍及全球。
你想啊，要是把Twitter或者微博服务器端开源，没几个人有那么多服务器去建立一套微博服务。最终还是只有少数几个服务。也就根本谈不上一个分布式全球服务。
现在讨论的问题，就是单指元信息。
kind 1，也就是普通消息，不存在被覆盖一说。
kind 3，用户contact list和relay list，Relay Server肯定要针对这个做一个处理，毕竟新的contact list来了以后，还给客户端发老的contact list肯定不行。
所以服务器对kind 3的处理是，来了新的，那么客户端查询时候，就发最新的一条，至于旧的删不删，协议要求删，但这完全是server端是否遵循协议的问题。
或者说，可以把Nostr Relay Server的设计，当成一个消息队列服务器。
不管是一开始就广播，还是用户post时再广播，只要不查历史数据，直接发新数据，就会覆盖Relay Server上的信息。
Nostr的核心思想是，Relay上不要做太多事，就是存储，删除，完全靠created time和id来对应消息，剩下很多拉取，合并等工作，要在客户端完成。
metadata也是历史消息
所以我的意思是，一个keypair，在某个或某几个Nostr relay，完全是个独立身份。
CLI message from 5601 6
查了旧数据/没有，然后再去广播，就能有效避免历史信息被覆盖。
你说的方法：用户登录新客户端后，手工添加原来使用的relay
这种方式，在这个不分青红皂白就广播的客户端上，恰好可以清空用户历史数据。
CLI message from 5601 5
所以说，重点是，在第一次广播前，要先去查历史，别啥也不查就去广播数据。
理论上删了也没事，顶多就是以前发的信息拿不到了而已。在新relay servers上开始新生活。
在Nostr世界里，一个keypair可以有平行宇宙的生活。
介还差不多……