No, it's mostly just the core structures that I use. I could migrate to go-nostr, but nostrlib is genuinely better in this area.
I attempted to switch to rely this morning and decided against it for now due to the lack of negentropy and blossom support. I get not wanting to include that stuff, but examples or external libraries would make the process easier (I do think negentropy should be table stakes for relays nowadays).
Thanks for the feedback.
To me, blossom is an orthogonal thing, which can be added in this way:
- create an http server (there are many many frameworks in go, even the standard library is fine).
- create a relay
- use the relay handlers in the http server (relay.ServeWS, relay.ServeNip11)
- add the blossom handlers to the server
and voilà, server is now relay + blossom.
For negentropy, that is another story since it used the websocket protocol.
It would be a nice addition to rely, so I'll add it to the roadmap. I am just conscious about complexity in general, since I want to maintain rely long term, not leave it rotting.
Absolutely, I think that breakdown is the right call. A blossom library could be built separately
How about a new library that has only data structures, no dependencies, minimal utilities like a relay pool, Query, Subscribe, and very performant JSON marshalling / unmarshalling?
Man I am so tempted to build this
I would entirely skip the networking code, but yes
my relay #orly has a blossom server built into it now. the library has the fastest event codecs for both the database binary version and the json, i just finished adding a feature where it can now load the libsecp256k1 library as a dynamic linkable without the cgo complications (you just need a version of the library with schnorrsig extension on). it doesn't have negentropy but i have built a sync protocol that lets you build a cluster that stays in sync, and using the new policy engine you can specialise nodes to only replicate some specific criteria of events.
i probably should put negentropy in there. easy enough to copy it out of khatru.
oh yeah, i forgot, the orly repo libraries also have an NWC client implementation, and it's used in a subscription whitelist system.
users pay for subscription by zapping the relay's npub btw.
man, how about we collaborate on a simple library with only data structures, JSON encoding and cryptography?
A standalone library would be easier for others to use.
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.
Okay thanks, at some point in the future I'll give it a go.
yeah, btw, i intend to have it so you can use the code and run the relay on all platforms, linux, windows, mac, android and ios. on ios it needs to fall back to the swift implementation and probably the kotlin one on android but the dynamic loader works for all desktop platforms.
i want to make mobile apps. i'm also concurrently working on a fresh new Vulkan based immediate mode GUI library with a neat and concise fluent chained methods API, i expect in a few months that will have reached the point where i can actually build a small simple app with it and it's pure go, no CGO, and faster than fear
(and will let you have one codebase that includes the web app version)
That's cool, but I am mostly interested in the low level foundational nostr library as I said
yeah it's only for the cryptography... signatures, hash functions. a lot of stuff SIMD or fast pure C it's worth having them available if they are found i think. when i used btcec to derive pubkeys to get this key i have now, it took over 3 days. now i can generate a -mleku key in about 5 minutes max, by using the libsecp256k1. so, anyhow, as far as that goes, i've got the crypto sorted out to be as fast as possible because verifying events especially is a huge part of the time spent processing
