Yep, that's the one
Discussion
Cool. Trying to understand how it works now. It’s making me think of JSON-LD, linked data. I’m thinking a context in JSON-LD plays a similar role to a namespace in nip 32, although I haven’t fully grokked nip 32 yet (and it’s been a while since I’ve thought about linked data) so I could be misunderstanding.
If I’m understanding correctly, a namespace L is basically a list of tags that we can use to look up what any particular tag means? …
nostr:npub1cpstx8lzhwctunfe80rugz5qsj9ztw8surec9j6mf8phha68dj6qhm8j5e
Meaning is entirwly based on convention, but yeah, I plan to create a page with my nomenclature on it that people can reference
Your nomenclature will be custom tailored to the purpose of a rating system for relays, I assume.
I wonder: Could the list of types at:
https://schema.org/docs/schemas.html
fulfill the role of a namespace? (Where a “type” at schema.org = an l-tag label in nip-32.)
And specifically, could
be useful for coracle’s relays rating system?
I’m wondering to what extent a variety of customized namespaces could be made interoperable / overlapping. Maybe schema.org augmented by whatever additional types a dev might need for some specific application.
I’ve been reading through the pull requests in the nips repo related to nip-32 and I can def sympathize with concerns by #[3], #[4] and others, particularly here: https://github.com/nostr-protocol/nips/pull/457, regarding defined vocabularies. We need them, but they are awful in so many ways. I may add some of my thoughts over there, but while the thought occurs to me I wanted to wonder out loud whether crowdsourcing a NIP-32 namespace — which is basically a defined vocabulary, if I am understanding correctly (and I may not be) — might be a potential application of (and potential way to test out the feasibility of) loose consensus using DCoSL.