One of the ideas I'm excited about is type schemas. In the spec garden there'll be a place to publish json schemas for every event type which will be versioned right along with the specs. I imagine this will make generating code so much easier.
Discussion
https://github.com/nostrability/schemata
Documentation soon™️
cc nostr:npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx
Awesome! So needed!
Taking another look this is cool! Why not turn on issues or are they tracked in another repo?
I turned on issues.
Excellent. I'm interested to look into this more later. Was it created for a specific project or what was the motivation?
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.
Days are getting shorter.
Released the specs I was talking about and they include an error reporting facility. Would love to get your thoughts. https://github.com/corgips/specs