客户端具体怎么实现这个广播效果的?登录之后就主动广播到公共中继吗?如果用户配置的公共中继很少甚至没有应该就没效果了吧?

Reply to this note

Please Login to reply.

Discussion

没有这么复杂,其实就是当用户修改了 relays 配置之后,客户端将最新的配置发到几个大 relays 而已。其他用户在需要查询你的事件时就去大 relays 查询你的配置,然后去对应的 relays 查询。如果你没有配置就要看客户端默认如何处理了

关键就在于这几个大的relay是谁配置的?客户端软件内置的还是用户自己主动配置的?我理解是要用户自己配置的,那么问题就来了,普通用户如何分辨哪些relay是大的哪些是小的?或者常用的流行的?

更别提大陆用户基本上都连不上那几个比较大的流行的中继的问题了😇

等这个模型跑通了,我们可以再想想怎么解决墙内的问题

我现在用bostr代理中继解决的,一个bostr服务器可以代理几十个upstream中继。

这也是国内的一种方式,国内可能不适合用 outbox model。我们可以自己探索一种策略

我目前的策略就是主要用的 inbox。一些像打开个人详情、私聊、回复帖子等有具体目标用户的场景,会额外打开用户的读或者写中继来读写数据(这就是 outbox 了吧?)。

算是了,只要你有将事件发送到提及人的 read relays 就很好了,这对其他客户端来说已经是莫大的帮助🫡

其实这类似于互联网中的 dns 解析服务器,确实应该支持让用户自定义。至于普通用户,不应该让他们设置。客户端应该有能力自动选择合适的。但现阶段有能力胜任这个任务的 relays 不多,所以客户端默认几个是合理的。

至于墙内的问题,很明显没有很好的解决方法,即使允许自定义,也没有能够胜任此任务的 relays。希望以后能有吧

我感觉要维护个专门维护这种中继信息的中继

类似bt协议的dht节点?不过这又引入了中心化节点了。。。

只是简单地保存提供查询类似某个人的中继列表等信息,相当于路由功能。以前做过这种 dht 程序,第一步也是尝试从这种中心节点获取一些信息,虽然节点是中心的,但是挂了也不影响使用,优化查询效率而已。

那就得先把账号的相关信息先保存上去才能查询。干脆把用户元数据信息在中继之间互通就行了,数据可以不互通。这样每个中继都有完整的用户列表信息了。

不用客户端主动保存上去,需要中继自带robot去各个中继去查询回来。其实如果做好了,拿到大量用户数据,能做做数据分析什么,有兴趣的童鞋可以动手试试。

是的

为啥我的nip-05在 #jumble 里面无效,其他客户端比如 #amethyst #nostrmo 都能正常显示?

没设置好跨域,网页客户端会有问题

搞个代理服务器专门来处理这种 nip05 和图片跨域打不开的问题。不然 web 客户端一直打开一些不可信服务器资源,始终有安全风险。

不过代理图片这个成本貌似挺高的。。。

nip05 倒是可以走代理,图片成本太高了🤣 不要直接使用密钥登陆的话问题不是很大

我看好多中继服务自带的nip05也不能正常显示,看来不是我自己一个人的问题。

很多人都忘记设置了🤣 NIP 中还专门提及了要添加 Access-Control-Allow-Origin: * 头

按ai给的跨域配置参数加上去果然好了💯