I've started using go-nostr as it was the main (and only) nostr library for go, also because I used khatru before building rely.
I've contributed 3 PRs to it, each time after seeing my projects panic in production.
The first time, because the event CheckID method panic when the event had a shorter ID.
The second time because it tried to access a tag without checking it was there.
And the third, because I've discovered a data race that originated from completely misusing goroutines.
https://github.com/nbd-wtf/go-nostr/pull/183
The first two were silly mistakes, but the third really highlights a pattern I found in the whole library:
The abuse and misuse of goroutines, the overcomplicated and convoluted patterns to provide synchronization.
I've looked at the new nostrlib, admittedly not much, but I've sees the same bad patterns over and over.
So, my current thinking is that, if I'll migrate, I'll probably migrate to a simpler library that only provides the data structures for nostr, which is the only thing rely uses.
Also because the JSON encoding / decoding can be made much more memory efficient, which would benefit relays a lot.
So yeah, long rant 😝
Thanks for the explanation, I was thinking "why not khatru" during all the video.
It's very useful to know why you decided to build a new project from the grounds up. I recall nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku also had sync issues with khatru, and he also builds a relay, called 'realy'.
Now really, we have rely, realy as relays. I guess it's not easy to google them if something goes wrong... :D
No replies yet.
