Every time I make a big release of applesauce I get tempted to go back and build more... I really should move on and actually implement the features I've added into noStrudel
On a totally unrelated topic. what do the typescript devs thing about building a library of zod schemas for common event types?
I've been trying to think of how to prevent invalid events from getting to the UI components and causing a crash and I think strong types with validation might help
Great idea.
Surprised it hasn’t been done yet.
I think I saw someone else working on it. nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5?
It was either a JSON schema library or zod, idk. but I have the urge to build my own now
Seems like a task AI can do a really good job with.
MKStacks probably already knows all the schemas.
Because the legwork is mostly constructing the json schema from the nips and there are A LOT of nips.
My plan is to use AI to generate the schemas (and them manually review them) but I don't really care to target AI. The applesauce SDK is primarily for developers and secondarily for AI.
My thinking is if its super easy for developers to use, then if the promise of AI is true, it will also be good for AI
I started working on this generic schema that could be used for that: nostr:nevent1qvzqqqqqqypzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qydhwumn8ghj7un9d3shjtnhv4ehgetjde38gcewvdhk6tcqyz5a04nmem34nh3jd88g5vhv0ww2pu4l6l4xtphyqa9eartnn4u2k5z9a5u
It would be great if you took a look and helped fix the AI bugs.
There is also this simple validation method in Go: https://gitworkshop.dev/fiatjaf.com/nostrlib/tree/master/schema/schema.go
By the way, nostr:npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr GitWorkshop doesn't display the latest commit for that repo on my browser, but it does if I open a new incognito browser window.
hmm... I was thinking of using zod because its a fancy new typescript library. but there is merit in having a language agnostic schema
Although it wouldn't work with typescript unless I built a compiler from schema -> zod -> types
nostr:npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx proposed schemata is per issue, extensible to any language.
nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr - regarding zod, nostr:npub1xzrkzsrnr83vn7h0udq6tnapwpswy5equlrtkn3nu0e0anlmzynqne0qap went through the pain of zod schema, and to my understanding is in agreement with nostr:npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx that the schemata approach is the most flexible/extensible for the variety of nostr applications.
https://www.npmjs.com/package/nostr-commerce-schema
nostr:npub1xzrkzsrnr83vn7h0udq6tnapwpswy5equlrtkn3nu0e0anlmzynqne0qap is also looking at extending to e.g. mkstacks.
Regarding the validation application - yes for applesauce this is a great use case for schemata.
nostr:npub1xzrkzsrnr83vn7h0udq6tnapwpswy5equlrtkn3nu0e0anlmzynqne0qap what issues did you run into with zod? I've done zero research on this but I know the AI models are have easier time writing zod and JSON schema so my thinking was to use them to produce the schemas
The big argument going round is that they don’t handle tuples effectively, Nostr tags are tuples, effectively, and I’ve experienced quite a lot of false-positives-and-negatives using Zod, requiring pretty unintuitive code-jitsu to remedy.
Are the issues with tuples in the generated typescript types or the validation of events. Looking at their docs they do have a tuple type and it seems to support rest types [string, string, ...string]
I'm curious because I like zod. although the more I look into this I'm thinking a JSON schema approach might be simpler then limiting it to TS
Great question, and definitely worth exploring / validating. Keep me in the loop, I’m all-brain-elsewhere at the moment but in a few months I’ll be asking these juicy questions.
I think cross-language availability is a big selling point for JSON schemas, as well.
Need to do more testing, but I tend to agree. JSON schemas would allow any language to use it, although I'm worried that some of the stuff like pattern matching or strict Typescript types might not get compiled. and thats mainly what I'm after.
I want to call a isContacts method in typescript and know for certain that all "p" tags have a hex value
Schemata is here:
https://github.com/nostrability/schemata
https://www.npmjs.com/package/@nostrability/schemata?activeTab=readme
nostr:npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx nostr:npub16ux4qzg4qjue95vr3q327fzata4n594c9kgh4jmeyn80v8k54nhqg6lra7 nostr:npub1xzrkzsrnr83vn7h0udq6tnapwpswy5equlrtkn3nu0e0anlmzynqne0qap
Auggie is looking at nip-10.
Acea will port a nip-99 marketplace schema in the next months.
Reporting for duty! Just, a little early lol
