my work is CC0 :) feel free to copy the algorithms and tidy up the API, i'm familiar with it in its current state but maybe it can be polished more.
one of the things that will be unfamiliar is that it uses raw binary formats for the fields that are hex in the events. this means their comparisons happen twice as fast. but it throws up some gotchas for young players and plenty of times the LLM mangles things and is comparing the raw decoded binary with the not-decoded hex.
also, the JSON codecs for filter and event take a lot of strict checking shortcuts because basically nobody uses json codecs that make these errors although they always have these linter checks through the encoder. and i wrote them using labels and goto btw :) much faster and more memory efficient for simple state machines.
the other thing is the new "purego" secp256k1 library i have put together - it dynamically loads the binary library if it can find it and uses the much faster C code from bitcoin core. it complicates deployment in that to make use of it you have to put the library in there, and ideally you enable all modules, but it must have schnorrsig enabled. if it doesn't find the library it should fall back to my new pure go library that does all the key nostr crypto operations faster than btcec.
i'll just stick to using next.orly.dev directly for other things but if you make the same performance available with a more polished UX that would be fantastic.
