继续分析推荐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
#[1]
刚看到有人加了100多个relay，这让我想起伏地魔为了长生不死制造了7个魂器。
【Relay学 #Relaynology 】
之前提到过，nostr的核心在于relay：
1.用户的global信息流来自他配置的relay
2.用户发消息时是推送到他配置的relay
3.粉丝关注某个用户时，是从该用户配置的relay拉消息（而不是粉丝自己配置的relay）
4.relay可以自由选择接受或者拒绝用户（收费、反垃圾）
5.relay可以自由选择接受或者拒绝消息（自定义应用、反垃圾）
6.用户可以自由选择relay（并迁移消息）
同时由于relay之间不需要p2p同步消息、上链，因此nostr协议是没有共识的，各个relay仅仅是松散地选择性遵守NIP标准而已。
这一点其实和http协议很像。
最初http协议仅仅是承载静态html页面，后来配合cgi、web容器等技术实现了动态效果。原始的apache httpd 早已不是最流行的实现，而各个web server也仅仅是松散地选择性遵守RFC标准。
雅虎、马云在上世纪90年代做网络黄页时，应该也没有想到简单的http协议会诞生如此大的帝国吧。
因此，随着NIP的逐步完善，relay和客户端实现的多样化，nostr将会“分叉”，但其生态有望更加丰富多彩。
#[1]
再补充一条：
6.POW验证Relay
POW验证有两种：
（1）验证公钥地址
这种目前见到的比较多，比如要求16进制公钥前面要有8个前导0才能加入relay。
这种方式有个缺点，就是需要新生成公钥，而Nostr用户可能已经有公钥了，迁移成本较大。
（2）验证Note ID
这个在NIP-13里有所提及，暂时还没看到实现。每个 Note ID是对消息sha256得到的，因此可以relay可以只接受符合难度要求的Note ID。
由于计算消息sha256时不需要签名，因此挖Note ID的过程也可以付费外包给第三方完成，这就使得在手机等性能较弱的设备上也得以实现。
#[0]
【脑洞猜想未来的relay类型】
最近各种收费或免费relay如雨后春笋般涌出。就像99%的山寨币都会归零一样，大部份的relay最后也都会关站跑路。
于是脑洞猜想一下未来可能长期存在的几种relay形式：
1.免费公共relay
充斥着广告、垃圾信息，连接速度缓慢；因为存储成本限制，只能保存最近3天的消息。
2.社交验证relay
连接前需要验证邮箱、手机号、twitter账号等，提供简单anti-spam，只保存最近7天的消息。
3.月租收费relay
和手机卡一样，需要充值才能使用的收费relay，速度快，广告少，可以拉取一个月到一年内的消息。
4.历史归档relay
保存了尽可能久远的消息，按照查询数据量收费。
5.大V名人relay
仅对KYC的用户开放写权限，其余人只读，速度快，无垃圾广告。
你觉得可能还有什么类型的relay？欢迎留言转发补充😊
会不会存在存在重放攻击的风险？
如果某些恶意relay拿到你的消息比如follow操作，它可以一直全网重放，最后导致你无法取关。
【忒修斯之nostr】
刚才脑洞想到一个问题：
假设我一开始使用的是默认的7个relay。然后随着时间推移，由于某些relay不可用或者连接缓慢，被我逐步删除，替换为新的relay，那么这些新relay能通知到我的所有follower吗？
如果无法通知到follower，那么在替换relay的过程中，我的原先7个relay里的follower就会逐渐丢失，而我毫无知觉。终将有一天，原始的7个relay全部被替换，而最初的follower就全丢了。
看了一下 nostr协议，似乎每次用户发note时都带上当前最新的推荐relay列表（不知道理解的对不对）但这样也有两个问题：
一是假设一次性替换全部7个relay，期间没有发note，那么还是会follower全丢。
二是假设某个用户只能连接7个relay中的1个节点A，然后我这次碰巧把A删掉换成了B，即使该用户能连B，但这个follower还是会丢掉。
这可能就是去中心化的代价吧。
分享两个damus使用小技巧：
1.你可以@其它用户：
方法是 “空格@公钥”，注意@前一定要有空格，否则会解析失败。
公钥可以从用户资料页复制npub开头那一串字符，或者长按消息Copy User Pubkey。
举例： #[0]
2.你也可以在消息中引用别人发的消息：
方法是“空格@消息ID”，同样注意@前的空格。
消息ID可长按消息后Copy Note ID。
举例： #[1]
这条更正一下，感谢大佬#[0]提醒。
这里之所以出现红色感叹号，并不是因为snort.social歧视，而是因为nost.vip的实现没有完全遵循NIP-05，没有处理好浏览器跨域的问题，所以导致snort.social作为Web客户端没法去验证，只能显示为红色感叹号。
这也就解释了为什么在damus客户端上显示是正常的。
我没有认真调研，导致发出了错误的言论，在此向大家道歉。
#[1]
今天看到很多人在讨论relay审查的问题，手动置顶一下昨天发的这个：
#[0]
上条好像引用失败了🙀
可能很多人没有意识到nostr的本质：
任何人都可以运行一个自托管的relay，他的言论都发到这个relay上，follower可以通过这个relay获取作者的所有言论，无人可以审查或者删除。
这个其实很像早期互联网的个人博客。
而公共relay是体现不出去中性化的。
🤪
Banishment This World