if there was a nostr v2 that required outbox in nip01 it would be strictly worse.
Discussion
Ok, I'll bite, why?
because outbox makes sense for some use cases (social networking) but not all
I think of outbox as "putting stuff where it's supposed to go" which is a little tautological, but basically requires defining where any given note is supposed to go. Not defining a "correct" home for a note basically guarantees failure to find it when it's needed. Outbox as currently defined doesn't cover all cases, just (public) social media.
I see it the same way. Having SOME defined way of determining which relays to use, rather than having NO defined way and blasting. That's all. It doesn't have to be the current NIP-65 advice. But it has to be something. Or else we end up with a network that uses 1000x more resources than it needs to.
But I guess I should expect bitcoiners to not care about using 1000x more resources than you need to. 🥺
BOIL THE OCEANS
also for relatively strong protection of privacy for direct messages
and for relay developers to control what the clients are making requests for, and there's some serious privacy implications about sending out quite revealing requests to all and sundry
actually, you know what, the reason why i think you are not entirely warm to it is because of the problem of propagation of messages that are intended to be completely public, ie, kind 1 TextNotes
and you'd probably be right to a certain extent, indeed, i could make an argument that these should be dumped in a content addressing storage system like Blossom or IPFS and become instantly available everywhere
yes, i'll agree with this... if the data is MEANT to be public, then it should be. kind 0, kind 1, definitely blaster model works better
requesting it, on the other hand, i think the out-bound should for "public messages" should be indiscriminate but - think about it, if the broadcast of public messages was already broadcast then you wouldn't need to look for them, either... your local relay would know how to find them, the one you pay
i've been working on a project that involves building a relay with a massive public "blockchain" based database, and now we are looking to actually do this with Arweave AO, which if you are not aware of it - someone started working on an arweave based relay about 6 months back, but abandoned it, i guess they got a grant, but arweave implements a content addressable, immutable append only storage system also
personally i'm much preferring the idea of Blossom, which simplifies and takes the "consensus" part out because why need consensus anyway, it's a broadcast, the data is public, nobody who published it cares, they want it to be public
this just isn't the case for DMs, and i've written extensively about the problem of privacy and metadata leaking, while we still can't have a monetised onion routing system where we can privately set up rendezvous points for our private messages without the problem of spam or traffic analysis, i'd rather trust a nostr relay operator who i constantly read and follow please
I agree with will