It's easy to take shots from the cheap seats (not what Derek is doing) and certainly not my intention, but this is fair and necessary criticism. As I keep repeating, we need fewer features and more QA.
There is no path to broader adoption without *quality* on par or better than the alternatives.
💯 I don’t think anyone who has been here for a while is taking shots from the cheap seats. Users who are actually using these apps and are sharing their wishes and frustrations are the best feedback any dev is going to get. They’re fools if they don’t listen.
Until QA becomes a higher priority, Nostr won't see sustained growth. It might not be sexy, but it's the true path forward.
nostr:nprofile1qythwumn8ghj7ct5d3shxtnwdaehgu3wd3skuep0qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcqypu8xwr40lp96ewdj2fef408wy70gd3carf9n6xu7hrnhq6whpgly925h0z , nostr:nprofile1qy28wue69uhnzv3h9cczuvpwxyargwpk8yhsz3rhwvaz7tmed3c8qarfxaj8s6mrw96kvef5dve8wdrsvve8vvehwamxx7rnwejnw6n0d3axu6t3w93kg7tfwechqutvv5ekc6ty9ehku6t0dchsqgrwg6zz9hahfftnsup23q3mnv5pdz46hpj4l2ktdpfu6rhpthhwjv0us2s2 , nostr:nprofile1qyv8wumn8ghj7urjv4kkjatd9ec8y6tdv9kzumn9wsq3vamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet5qqsqfjg4mth7uwp307nng3z2em3ep2pxnljczzezg8j7dhf58ha7ejgqgzx3h , has anyone applied to build a test suite for nostr?
Is there any reason to think this is an unreasonable task, nostr:nprofile1qyghwumn8ghj7vf5xqhxvdm69e5k7tcpz4mhxue69uhkzet8d9ejuat50phjummwv5hsqgpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5zgwjy3 , nostr:nprofile1qyw8wumn8ghj7un9d3shjtnzd96xxmmfdecxzunt9e3k7mf0qy2hwumn8ghj7un9d3shjtn4w3ux7tn0dejj7qpqutx00neqgqln72j22kej3ux7803c2k986henvvha4thuwfkper4sau8ykj ?
nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5 had an idea of NostrCI. Not sure if that went anywhere.
I'd bet on him.
Ehhhh, I don't see how a generic test suite would catch the types of issues Derek is pointing out, but perhaps I am regarded . Usually they have to be app specific and extremely well planned out to catch crashy type scenarios
nostr:npub1zafcms4xya5ap9zr7xxr0jlrtrattwlesytn2s42030lzu0dwlzqpd26k5 has wanted something like that for years and I always tell him it's an impossible task.
I think he just means a common test suite
Yes. I'm not a dev, so I'm reaching, maybe, but is it not reasonable to build test suites for the most commonly used libraries?
nostr:npub16ux4qzg4qjue95vr3q327fzata4n594c9kgh4jmeyn80v8k54nhqg6lra7 is working on a nostrCI proof of concept. More details to follow
Not impossible, fairly simple POC. Once the poc is done it's at matter of getting funding to grind out use cases. The matrix of use cases is also fairly trivial to generate.
Likely the hardest part will be the mobile testing.
Probably the idea would be to run these on nostr:nprofile1qqsthdwa5rs42euhnuz5xsrmmssr84hshwes7uj392vpeldj7z0zw3cppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg3waehxw309ahx7um5wgh8w6twv5hsef7u3d's cicd DVM so anyone can trigger and pay the invoice.
We can use nostr:nprofile1qqswwud0pvzu362lehm0av6sq4zd97cue5uy0z8f7jgtk0hz368dvmcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxmhwden5te0wa5x2ct59e5xzurs096xzan9wfhzucm09uqsuamnwvaz7tmwdaejumr0dshsdms043 's validation tool, running them on decentralized (GitHub actions) workflow runners using gitworkshop.
These are up to date, with some known inaccuracies (and in production use)
Schema: https://github.com/sandwichfarm/nostr-watch/tree/next/libraries/schemata
TS/JS Validators: https://github.com/sandwichfarm/nostr-watch/tree/next/libraries/schemata-js-ajv
I'm confused what I'm looking at. This isn't something for testing, it's for validating data as it comes into the relay, correct
It's for validating data, in general. A huge percentage of interoperability issues between clients relates to missing tags or missing data within tags.
Validation and QA are different things tho right? Or am I thinking about this incorrectly
Not sure, I was just primarily responding to nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qgwwaehxw309ahx7uewd3hkctcprpmhxue69uhhyetvv9ujuen0w4h8gctfdchxvmf0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcprpmhxue69uhkzapwdehhxarjwahhy6mn9e3k7mf0qyvhwumn8ghj7er9wfnkjemf9ehx7um5wgcjucm0d5hszythwden5te0xy6rqtnxxaazu6t09uq3wamnwvaz7tmzd96xxmmfdejhytnnda3kjctv9uq3wamnwvaz7tmzw33ju6mvv4hxgct6w5hxxmmd9uq36amnwvaz7tmgdyhx67tkda5kxet0w4e8xar0wfujummjvuhszgrhwden5te0vf5hgcm0d9hx6ctcd9kkzmrfwd68xtn0dekxjmn99uq3qamnwvaz7tm99ehx7uewd3hkctcpr9mhxue69uhkwun0w4c8xtnxd9shg6npvchxxmmd9uq3jamnwvaz7tmvd9nksarwd9hxwun9d3shjtnrdakj7qgmwaehxw309ankcetpwdhkuct5daezuer9wchhyetvv9uszrmhwden5te0gphx7uewd3hkctcpr9mhxue69uhks6ewwp6hyurvv4ex2mrp0yhxxmmd9uq3wamnwvaz7tmpw3kxzuewdehhxarj9ekxzmny9uq3vamnwvaz7tmgd9ehgtnwdaehgu3wd3skuep0qqsthdwa5rs42euhnuz5xsrmmssr84hshwes7uj392vpeldj7z0zw3ctsk94x since he linked to the nostrability repo that hasn't been updated in almost 6 months. Wanted to clarify.
If Client A puiblishes a NIP-22 events without a root event tag, then Client B (and perhaps event Client A) won't be able to find it. Schemas can catch this error either in production or in a CI/CD pipeline. It can also detect these issues by fuzz testing events.
I would personally consider that QA, but maybe not?
nostr:nprofile1qqsthdwa5rs42euhnuz5xsrmmssr84hshwes7uj392vpeldj7z0zw3cppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg3waehxw309ahx7um5wgh8w6twv5hsef7u3d what are you getting at? I'm unsure how you're saying to use this for qa. Like I get it for apps to use, but I don't understand what you're saying about using this when testing clients.
Validation can be one task in the process of QA. It's not the whole thing but def important
But why? The whole point of QA is to use broken events and see how the clients react. Also, it's to use working events and see how they react. Once the test data is generated you won't really have to validate? Sorry I think I'm missing something
