啊?! 一直以为 jumble 是某位外国开发者主导的QAQ

big relay 是因为我在连接本地中继测试的时候我发现客户端会不受控制的去连接其他中继, 然后就直接断网测试了...

Reply to this note

Please Login to reply.

Discussion

我刚把jumble读写服务器都删掉确还能收到信息,就是内置big relay的原因?

作者内置一些中继用于在初始状态连接到中继来做基础的信息推拉, 所以即使你没设置这些中继其实也是连着这些中继的

对于没有设置读写服务器,或者设置太多(超过 8 个,我认为用户不了解其作用),Jumble 会不采纳这些配置,为其降级为默认读写中继器以保证基础使用体验

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) 事件约定

jumble 也是完全遵守的,关注人多的话一次连上百个 relays 很正常,只是没显示出来。然后浏览器会阻塞掉一些连接,许多功能就不正常了😌所以我不建议在遵守 outbox model 的网页客户端上浏览关注人 feed,即使是原生 app 没有被阻塞一些连接也是非常消耗资源的。

所以我推崇直接浏览各种有意思的 relay,然后只关注少量用户。随着不断去中心化,通过关注来获取 feed 的方式会越来越不可取

我最讨厌nosotros的部分就是链接百来个中继,在低数据下直接就是feed empty,因为中继一直在加载未完成…