What if I want my events sent to many relays. You can say outbox should solve the need for posting to a bunch of relays but I really think the more relays your event is on the more reach you have. Also the more redundancy of your data and this censorship resistance.
Discussion
That's a fallacy. The benefit of every additional relay diminishes incredibly rapidly. How likely is it that you'll be censored from a rely? 1%? That means being censored from both simultaneously is a .001% chance. At three, you're at a .00001% chance. Choosing 3-5 relays based on incentives is infinitely more effective than sending notes to 500 random relays.
As for increasing reach, that is only the case if a relay 1. allows you to write to it and 2. is used by other parties to execute requests matching your notes. Non-Outbox relays like that exist, (community relays, wot relays, paid relays), but again, in a given context. Randomly broadcasting only increases your reach if you happen to hit a relay you should have been able to select manually (or automatically).
Tldr, you're trying to brute force content distribution. It just doesn't work that way.
For more details: https://habla.news/u/hodlbod@coracle.social/8YjqXm4SKY-TauwjOfLXS
I have to rely on the fact that a client will use outbox and forget the fact that global exists. I'm still not seeing it... With blaster I can verify my note has distribution and not trust that it does. At least distributtion to all free public relays. I get you want to reduce the amount of redundant data out there for nostr, but that doesn't mean out of gets your note note in front of just as many eyes. I wish we had more analytics instead of opinions.
The whole network has to rely on that fact. If we can't achieve correct relay selection the whole project is pointless. Scaling the same way bluesky is (copying every note to every node) isn't meaningfully decentralized.
Now I see that perspective. Kinda how Bitcoin nodes sync with each other in a way.
Every bitcoin node has a full copy of the blockchain, which is why it's so important to keep block sizes low. Nostr relays won't possibly be able to store a copy of the full multi-zetabyte network at scale (and don't have a consensus protocol anyway)
Yes that's why I said in a way
Follow a protocol so to speak. I didn't mean every relay store everything. Perhaps nip1, the only required nip, should have provisions for outbox model for clients if this is how we think the protocol should work.
in theory, relays could become clients to other relays and forward requests
i have an interface for this kind of multi-level event store interface built into my #realy event store library, i have implemented a shitcoin layer 2, and two things i have penciled in for the future is a blossom store that can only search for event IDs (first layer must contain indexes) and a second model is where relays use each other as event stores and forward queries to other relays and cache the results for the relay's users
these are two distribution mechanisms i have in mind for how nostr scales a lot further, i believe there is similar kinds of multi-node query forwarding design in blossom too
ultimately this is a massive privacy and bandwidth benefit because one can rent a few good, reliable, fast, local relays to do your relay work and they automatically sync up with what you want to see from other relays but they make the requests on their behalf, which means you don't get seen doing it, and you don't waste your bandwidth doing it, and because it caches, it doesn't have to be done again if other users on the same relay want to see that content
lack of partition resistance in nostr is not a bug, it's a feature
there is no consensus
social communication should not be a consensus, but rather, a constant process of convergence, that never reaches the destination
they will all understand one day
you can't bo business communications without partitioning, and we have already seen the impossibility of the silos allowing both fanatical marxists and normal people in one pool