Yakihonne 的最新版居然开源了, 之前我跑的时候还是一个老得不行的版本, 而且上个月仓库好像还被归档了. 今天想着看看 Nostr 社区最近发展得怎么样, 就顺手去瞄了一眼...
虽然...呃...是用 Next.js 写的, 不过它在中继连接管理和事件发布这两块确实比 Jumble 成熟太多了.
顺带说个自己的发现: Jumble 的设计里把 Big relays 给 const 死了, 强制会连接这些中继做 bootsetup, 一旦这个列表里的全部中继出问题, 就算你额外配置了其他中继, feed 流和各处的 profile (kind-0) 也都加载不出来, Jumble 能这么火应该是矮子里挑高个才...
当然 Yakihonne 也不算完美, 它那套 "智能组件" (美丽的废物) 改天得 fork 下来自己删一删.
Nostr 都发展到现在了, 居然还没有一款完美的客户端. 要是能有个融合了 `Jumble`, `Nostrudel` 和 `Yakihonne` 优点的客户端就好了. 睡觉了, 梦里也许什么都有 😢
Login to reply
Replies (14)
big relays 主要作用是获取用户设置的额外 relays,profile 如果没能从 big relays 获取,是会从用户配置的 write relays 获取的。当然如果 big relays 都挂了,那问题是挺大的,因为我也不知道该从哪里获取其他用户配置的 relays 😌
感覺又是個敲代碼高手嗎?等他整合個super nostr 客戶端😂
期待☺这样我又多一个可以抄的对象
那个Openvibe不是整合了nostr,长毛象,bluesky,用起来也还是不错。
啊?! 一直以为 jumble 是某位外国开发者主导的QAQ
big relay 是因为我在连接本地中继测试的时候我发现客户端会不受控制的去连接其他中继, 然后就直接断网测试了...
其实是我在抄您的...因为您的客户端 UI 目前是最好的QWQ
我刚把jumble读写服务器都删掉确还能收到信息,就是内置big relay的原因?
作者内置一些中继用于在初始状态连接到中继来做基础的信息推拉, 所以即使你没设置这些中继其实也是连着这些中继的
outbox model 是这样的了,当你要查询某个用户的事件时会从这个用户配置的 write relays 上查询,当你要查寻某个帖子的回复时,会从主贴的作者的 read relays 查询,当你提及某人时事件会被发送到此人的 read relays 上…… 这种模式下客户端会自动连接许多其他 relays,这对去中心化是有作用的,当然牺牲了一些隐私,因为会连接许多你可能不想连接的 relays
要实现以上逻辑,客户端首先需要一种高效的方式查询用户的 relay 配置。现在大家的做法是将用户的 relay 配置发布到一些大型公共 relays 上,查询时也从上面获取。严格来讲我不应该将其命名为 big relays 应该叫 index relays
对于没有设置读写服务器,或者设置太多(超过 8 个,我认为用户不了解其作用),Jumble 会不采纳这些配置,为其降级为默认读写中继器以保证基础使用体验
我只是 shadcn 的搬运工,一年前刚学的前端不会写复杂的 UI 🤣
确实, 之前看到过 fiatjaf 的文章提到过 https://fiatjaf.com/bc63c348b.html
目前在隐私和各种中继模型我发现的只有 nostrudel 是最完善的, 然后抗审查方面 nosotros 这个是最疯的, 每次打开它会连接上百个中继服务器, 我估计他是完全遵守了 nip65 (kind 10002) 事件约定
jumble 也是完全遵守的,关注人多的话一次连上百个 relays 很正常,只是没显示出来。然后浏览器会阻塞掉一些连接,许多功能就不正常了😌所以我不建议在遵守 outbox model 的网页客户端上浏览关注人 feed,即使是原生 app 没有被阻塞一些连接也是非常消耗资源的。
所以我推崇直接浏览各种有意思的 relay,然后只关注少量用户。随着不断去中心化,通过关注来获取 feed 的方式会越来越不可取
我最讨厌nosotros的部分就是链接百来个中继,在低数据下直接就是feed empty,因为中继一直在加载未完成…