The motivation was to use the schemas in fuzz testing and to identify interop issues. I also use these, and more specifically the validator, on nostr.watch
How it wasnt built prioritizes maintenance and was written in TS for tooling; the js json-schema ecosystem dwarfs all other languages.
Planning schemas at the core of these new specs. I'm by no means an expert, just understand the value of spelling things out so I hope you'll share your thoughts once the drafts are out.
Just open a PR
Not sure if a PR is the way. Here's the repo which includes some initial /schemas. Really interested in your input, especially since nobody's used any of this stuff yet. https://github.com/corgips/specs
Looks redundant to @nostrabillity/schemata
Differences of corgips/specs to @nostrability/schemata (original)
1. Original uses yaml, which is easier to edit.
2. Original has a build system with a conventioned export pattern.
3. Original produces artifacts compatible with any language.
4. Original is inherently built to be modular by adding an alias convention; it is easy for schema to extend each other.
I would suggest contributing to @nostrability/schemata, as it's demonstrably better.
Forgot to mention that it has releases with artifacts (which would be used by validators of other languages)
I appreciate the comparison and agree on yaml.
I've seen some promising material in NIPs that's got me busy for the next couple days and if that doesn't pan out corgips/specs will see major edits driven by implementation work.
Before I get into that though I would take your advice and look deeper at @nostrability/schema. The more I see of the current state of things the less original content seems to be necessary.
It can be extended for custom kinds. Improvements should be made to make that easier.
