This can absolutely be done. If I want to find a list of nips and which ones are approved and which ones are rejected by my WoT, I should be able to look it up. That can be done without requiring much data storage.
My argument above was that we are probably irrationally shocked by the data volume of things we want to decentralize.
Collaborative curation would be awesome and we could start small but maybe not too small. I would love to move the nip registry onto nostr. Let nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 maintain a list of nips and other approve of the list or not. How hard can it be?
With the WoT idea, I imagine being able to refer to "nip1" in a way ... like %nip1 such that your client would know where to look up what my understanding of "nip1" is. If I define ["nip1", "fiatjaf.nip1"] in the right place, your client would get you there. I think there is little missing for this to work. The idea of pet names is there and the rest can be done with some parametrized replaceable events.
Discussion
Pretty Good Apps could curate a list of nips right now. Buggy and not very spiffy but the proof of concept is there.
One problem to consider is: what if Alice and Bob each claim NIP-101 as their own? Two different NIPs but same number? Answer: we need to use cryptographic identifiers, not human readable names, to refer to their submissions. Then the WoT picks one over the other.
That is where I see the use of pet names. You would not talk about "nip101" or if you did, you would have something in place that would resolve to an actual parametrized replaceable event via maybe indirection. Or you would explicitly reference Alice.nip101 and then the nostr client would search for Alice's definition of "nip101".
Probably multiple ways to handle this. In my stuff, any given chunk of data may have several ways of identifying it uniquely: universally unique ones like the data hash or an event id (which are immutable; there’s also mutable ones line IPNS names); then there are slugs which are semi-human-readable; and one of the criteria of a concept graph is that every node in the graph must have a unique slug. But of course, outside the graph the slug won’t be unique, which is why you need a universally unique id. (if you ever want to share the data with anybody, that is; which is frequently the case when we’re doing WoT) Within any individual concept, there may or may not be any unique identifiers (whether local or universal), which will vary from concept to concept.