Yakihonne 的最新版居然开源了, 之前我跑的时候还是一个老得不行的版本, 而且上个月仓库好像还被归档了. 今天想着看看 Nostr 社区最近发展得怎么样, 就顺手去瞄了一眼...
虽然...呃...是用 Next.js 写的, 不过它在中继连接管理和事件发布这两块确实比 Jumble 成熟太多了.
顺带说个自己的发现: Jumble 的设计里把 Big relays 给 const 死了, 强制会连接这些中继做 bootsetup, 一旦这个列表里的全部中继出问题, 就算你额外配置了其他中继, feed 流和各处的 profile (kind-0) 也都加载不出来, Jumble 能这么火应该是矮子里挑高个才...
当然 Yakihonne 也不算完美, 它那套 "智能组件" (美丽的废物) 改天得 fork 下来自己删一删.
Nostr 都发展到现在了, 居然还没有一款完美的客户端. 要是能有个融合了 `Jumble`, `Nostrudel` 和 `Yakihonne` 优点的客户端就好了. 睡觉了, 梦里也许什么都有 😢
big relays 主要作用是获取用户设置的额外 relays，profile 如果没能从 big relays 获取，是会从用户配置的 write relays 获取的。当然如果 big relays 都挂了，那问题是挺大的，因为我也不知道该从哪里获取其他用户配置的 relays 😌
啊?! 一直以为 jumble 是某位外国开发者主导的QAQ
big relay 是因为我在连接本地中继测试的时候我发现客户端会不受控制的去连接其他中继, 然后就直接断网测试了...
outbox model 是这样的了，当你要查询某个用户的事件时会从这个用户配置的 write relays 上查询，当你要查寻某个帖子的回复时，会从主贴的作者的 read relays 查询，当你提及某人时事件会被发送到此人的 read relays 上…… 这种模式下客户端会自动连接许多其他 relays，这对去中心化是有作用的，当然牺牲了一些隐私，因为会连接许多你可能不想连接的 relays
要实现以上逻辑，客户端首先需要一种高效的方式查询用户的 relay 配置。现在大家的做法是将用户的 relay 配置发布到一些大型公共 relays 上，查询时也从上面获取。严格来讲我不应该将其命名为 big relays 应该叫 index relays
确实, 之前看到过 fiatjaf 的文章提到过 https://fiatjaf.com/bc63c348b.html
目前在隐私和各种中继模型我发现的只有 nostrudel 是最完善的, 然后抗审查方面 nosotros 这个是最疯的, 每次打开它会连接上百个中继服务器, 我估计他是完全遵守了 nip65 (kind 10002) 事件约定
那个Openvibe不是整合了nostr，长毛象，bluesky，用起来也还是不错。
