这是一个问题，短时间内创建管理大量 websocket的开销。另外有个问题，要从哪里去找这些用户的 relay list（10002 kind），一些固定的大 relay？
Discussion
是的，outbox model 的说明文章里有提到客户端应该将 relay list 发布到尽可能多的 relay 上，所以可以简单从固定几个大 relay 获取
我觉得 nostr 生态缺少 nip65 indexer 的基础设施。需要很多只接受kind 10002 的小 relay, 这些 relay 对带宽和存储的要求都不要，但他们需要彼此能通信同步数据，专注于为应用提供查询 relay list 的功能。
我前段时间看到 coracle 的作者有发布这样一个项目来着，但目前来看同步到几个大 relay 已经形成共识，想要推进这个想法还是有难度的
还有一个想法，也许每个用户都应该只用一个 relay, 挂了就再换一个 relay，同时更新一次 10002 kind 的 event。这样对客户端会比较友好，同时仔细想想，其实好像也不比多用几个 relay 来得差——首先你更明确的知道你的数据在哪个 relay 上，同时 nostr 的应用一般都是 local-first 的，本地也有一个备份。相反，如果用很多 relay，其实反而让客户端和用户都很困惑：我的数据到底存在哪个 relay？于是很多客户端要做很多工作去猜，用户体验也变复杂。
其实一个和三四个区别不是很大，超过这个数的话，大部分客户端是不拿来参考的。Jumble 只会使用用户设置的前 2 ～ 4 个 relay。并且如果用户设置超过 8 个 relay，会直接认为这个人不懂 outbox，从而不使用他设置的 relay，默认使用几个大 relay。
现在 outbox model 还有一个很大的问题，用户在更换 relay 时并不会将旧 relay 的数据全部同步到新 relay 上，这会造成找不到他以前的事件