I don’t disagree in principle, but in practice… kind-10002 as it is now isn’t sufficient. This is a chicken-and-egg problem: I need to connect to an unknown relay to fetch Mike Dilget’s kind-10002 event in order to figure out which relay I need to connect to in order to find Mike Dilget’s notes. It’s a strange way of bootstrapping things unless we accept relay centralisation or widespread blasting / Negentropy. IMO, the first is undesirable, and the second is wonky, it introduces eventual consistency at best and indeterminism at worst.
This isn’t a criticism of the Outbox model by the way. It’s definitely the way forward, but I think we need an efficient, hopefully deterministic, single-call way of doing this. And this has to be done without relying on Damus, nos.lol, Snort or whatever other giant relays to hold every single kind-10002 (or equivalent) in existence.
On a more fundamental level, I think the "one true way of doing things" ship sailed a long, long time ago. Deprecating a NIP won’t help much either (e.g., NIP-04 vs. NIP-17 even with harassment bots and some popular relays like Haven dropping kind 4 by default, most clients aren’t there yet).
In a way, while this is the opposite of what I’d push for as an architect, I’m happy for Nostr to be the hacky, pragmatic "PHP of Protocols." Every programming language feature ever invented eventually finds its way to PHP, and we all know how hacky and clumsy parts of PHP’s standard library are. PHP, like C++, gives you at least 10 ways of doing anything. But unlike C++, a first year CS undergraduate can easily hack something functional with it.
And that’s totally fine, considering what Nostr aims to be. PHP won the web race, while my favourite, "well-designed" programming languages are all competing in niche spaces. This doesn’t mean your call to clean up Nostr is wrong, it’s just that… good luck herding cats into agreeing on and implementing one true way of doing things.
However, just to indulge in one true way thinking: if you put a gun to my head and told me to choose, while I’d personally pick DHT, in terms of driving Outbox model adoption across all major clients before 2030, I’d go with the "well-known URI on steroids" approach. Maybe with additional NIP-05 provisions to standarise identities behind onion services. Perhaps also with a dead-simple, optional PUT endpoint to update relay information trivially from clients. To me, kind-10002 should be part of nostr.json, i.e., it’s connection bootstrapping information and, as so, should be trivially obtainable before I even connect to any Nostr relays.
