because outbox makes sense for some use cases (social networking) but not all
Discussion
A bunch of months ago I considered whether we should have it on nip01 and discarded the idea precisely for this reason
It just so happens that the most common use case of nostr rn is the social media / broadcast model, but that’s far from the only case. Outbox applies very much for that case and very little for other use cases.
I suspect there will be many new ways to fetch notes in the future (p2p overlay networks), etc. nip01 just defining the packet is good.
I picture nips branching out as a tree. Maybe there is a root node that defines social networking nips, that specifies the outbox model as the way to fetch notes for that class of applications.
So in that sense I agree with nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c if this is what he means, but there will be other root nodes for other application domains with different ways of routing notes.
i'm of the opinion that events shouldn't have tags, tags should be in a context field of a specific kind, this would be one change i would make
i'm big on single responsibility principle, and more recently i have learned about Domain Driven Design... these two systems of thought about systems architecture both say you should keep things simple and tight, and use layering and not bake things with potentially different uses into a single monolith
and hey, that's one of the key disagreements between BSD/Darwin vs Linux/Windows kernels now
technically, the former is superior, more robust, more efficient, faster, lower latency, lower bug count, less exploits
but unfortunately the latter, in both cases, have proliferated like a virus
I would not put nip-65 into nip-01. I wholeheartedly agree with you that social networking is only a small part of what nostr can and will become.
But I do think there needs to be some advice about relay usage moreso than we have today, where clients fail to rendezvous and people try to fix that by blasting. Each use case will have potentially a different solution. I think inboxes and outboxes are general enough concepts to work in multiple use cases, but certainly not all, there are half a dozen use cases already that don't choose relays in that way (take nsec-bunker for example, or a livestream service, or relay-global feeds, etc).
I thought you said you think of nips as an ogre, I mean onion
Onion tree
Just realized this analogy is basically the same, with the root of the tree being the center of the onion. There could just be multiple onions.
onions don't fork, that's garlic
a similar idea was the original thought behind wikifreedia.xyz
what "nostr" means might vary for different developers
I had originally thought of the idea that ended up as wikifreedia as an editor where you could define what each NIP is, and, even if we got to have competing NIP implementations, at least the competing proposals could be documented.
Sort of like what you have with the DIPs repo, where stuff that wasn't "accepted" into the nips repo can (and does) still exist and be easily documentable/findable.
Where do you find a list of the NIP’s and DIP’s?
NIPs are on https://github.com/nostr-protocol/nips and DIPs on damus' github afaik -- not sure if nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uq3zamnwvaz7tmwdaehgu3wwa5kuef0qyt8wumn8ghj7un9d3shjtnddaehgu3wwp6kytcqyqewrqnkx4zsaweutf739s0cu7et29zrntqs5elw70vlm8zudr3y2k0udpw is still maintaining it
some NIPs are on wikifreedia.xyz, particularly NIPs I am using but haven't been merged yet I link to them on my "nostr" entry
This is genius. I've been thinking about various other applications that wouldn't operate well on the network as-is. I'm thinking beyond "social media protocol" and into "decentralized and distributed (platform-less) cross-application persistent identity, media storage and retrieval, and information security". Replace and tear down gatekeeping for MLS (real estate for those not familiar), for community governance (more secure and psudonymized voting, likely with a different npub), for commercial networking and markets with tiered profile structures, etc.
Having the option to branch the protocol to specialize into other applications that would simply not work well on a social-first paradigm would make these other ideas actually feasible.
Another reason I think this is the future is because AI is taking over so many spaces, but AI can't fake digital signatures, and the signing paradigm of Nostr is a shield against it.
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