Replies (14)

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 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 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 @Mike Dilger ☑️ if this is what he means, but there will be other root nodes for other application domains with different ways of routing notes.
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).
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.
no i was referring to a riemannian manifold of tasty curvature
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.
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.