美图Bot's avatar
美图Bot 4 months ago
outbox模型我感觉不太好用,要连的中继太多了,尤其是广场上的帖子,几乎可以说要连接到所有中继了。。。
Vitor Pamplona's avatar Vitor Pamplona
Outbox is harder than it should be just because devs make their first versions with a hardcoded relay list expecting that later they will just "add outbox". Nah... you won't. You fucked up. Now you need to rewrite everything because your architecture cannot handle it. It's as simple as that. Outbox requires many layers of indirections: Before loading the feed, you need to load the NIP-65 event, and before loading the NIP-65 event you need to figure out the user's home relay to get the most up-to-date NIP-65 event from. You will need to setup those layers from the beginning. More importantly: your relay pool will change from post to post. You will need to quickly disconnect and connect to relays as the use slides through their feed. To see all replies of a thread, you will connect to all of the inbox relays of each participant in that thread. That's the only way to see everything. The same pool must keep Bunker connections alive at all times and randomly connect to Nostur Wallet Connect relays to send zaps. If you are crazy enough to implement multiple NIPs, like Amethyst and Nostur do, each NIP will have their own ways of defining which list should be used. You will need different bootstrapping relays for each NIP. Our nostr libraries are terrible. They are almost all still based in the old thinking of a fixed relay pool. Even the modern AI stuff from @Alex Gleason still uses fixed relay lists. That will drive your code into a direction that will be very hard if not impossible to fix later. We can fix this. But it is hard to fix when every client also operates a main relay to centralize things on. Things get built around that relay and people forget to decentralize. It's sad. But this error is so common that it's not even fun anymore. Every client needs to help users setup their relay lists. Every client MUST use the user's relay lists that other clients already helped him/her setup. Ignoring the user settings from a different client will only make your code unfixable overtime. The happy path is evil. And if you go down into that direction, it will consume your soul.
View quoted note →

Replies (9)

😥 主要是这个东西,没写到 NIPs 里面,只在某个图片中看过 NIPs 里面有写了,每个人都配置有一些 **读中继** 和 **写中继**,**Inbox** 估计是主要使用自己配置的中继,**Outbox** 估计就是主要使用别人配置的。
那就是读/写中继的新叫法了。 其实吧,我觉得这个机制灵活性一般。 免费中继广泛存在的情况下,付费中继的内容都会被广播到免费中继,免费中继根据稳定性和延迟会存在一定程度的中心化,不需要这个机制,用户连接几个稳定点的就可以了。 如果中继广泛收费,那么这个机制有效,但要求用户对别人的INBOX和自己的OUTBOX都有写权限,用户干嘛还要买对方的INBOX中继。设计这个机制的想法应该是用广泛存在的免费中继补充INBOX,但那就回到上一种情况了。 即使这机制有效的场合下,这个逻辑也不应该丢给客户端处理,INBOX/OUTBOX一体化更简单合理,对方的回复也在对方的OUTBOX,我如果感兴趣可以自己去拿,互关的当然会看到,没关注的回复的通过关注链条上用户的再广播又可以看到一部分,再剩下的真就不重要了,自然博弈的过滤器。
看了,维持我的原来的意见😂 末尾的个人中继不就是这种一体化的情况么?其它中继同样道理,为啥非要把INBOX/OUTBOX分到两个中继上。
nodez's avatar nodez
再或者中继也要接受对白名单用户的回复和DM之类写入,这时候INBOX/OUTBOX还是变成了同一个。 不论免费/付费中继格局怎么变化,每个用户通过关注网进行路由式的再广播才是去中心化的关键。 View quoted note →
View quoted note →