outbox模型我感觉不太好用，要连的中继太多了，尤其是广场上的帖子，几乎可以说要连接到所有中继了。。。
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 nostr:nprofile1qqsqgc0uhmxycvm5gwvn944c7yfxnnxm0nyh8tt62zhrvtd3xkj8fhgprdmhxue69uhkwmr9v9ek7mnpw3hhytnyv4mz7un9d3shjqg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3vamnwvaz7tmjv4kxz7fwd4hhxarj9ec82c30hyvdwq 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.
Discussion
inbox 和 outbox 结合才是硬道理
inbox我也没理解，什么情况下才会用到？
😅 求个大佬，来解释一下。。。
你不就是那个大佬么？🤔
😥 主要是这个东西，没写到 NIPs 里面，只在某个图片中看过
NIPs 里面有写了，每个人都配置有一些 **读中继** 和 **写中继**，**Inbox** 估计是主要使用自己配置的中继，**Outbox** 估计就是主要使用别人配置的。
那就是读/写中继的新叫法了。
其实吧，我觉得这个机制灵活性一般。
免费中继广泛存在的情况下，付费中继的内容都会被广播到免费中继，免费中继根据稳定性和延迟会存在一定程度的中心化，不需要这个机制，用户连接几个稳定点的就可以了。
如果中继广泛收费，那么这个机制有效，但要求用户对别人的INBOX和自己的OUTBOX都有写权限，用户干嘛还要买对方的INBOX中继。设计这个机制的想法应该是用广泛存在的免费中继补充INBOX，但那就回到上一种情况了。
即使这机制有效的场合下，这个逻辑也不应该丢给客户端处理，INBOX/OUTBOX一体化更简单合理，对方的回复也在对方的OUTBOX，我如果感兴趣可以自己去拿，互关的当然会看到，没关注的回复的通过关注链条上用户的再广播又可以看到一部分，再剩下的真就不重要了，自然博弈的过滤器。
找到原文了，大家可以来看看
https://mikedilger.com/gossip-model/
nostr:npub17ryxfn6h8hshzpfmaaxl8vcuvkfnx7sf07aanusd0pgxujgvddjq7y9shm
看了，维持我的原来的意见😂
末尾的个人中继不就是这种一体化的情况么？其它中继同样道理，为啥非要把INBOX/OUTBOX分到两个中继上。