so, i'm trying a new thing with Junie

i've asked it to take the NWC package of https://github.com/getAlby/js-sdk and translate it to #golang

i'm sure it's gonna not work but it might be good enough that i can fix it and make it work.

why alby built half of their infra with go and never considered building the client/server parts of the NWC SDK so they can be used by go based apps is beyond me. but hopefully i will fix this, and i'm NOT porting it to go-nostr, because that is a bag of dicks, slathered in blueberry and pickles.

Reply to this note

Please Login to reply.

Discussion

man, the naming scheme tho. junie (claude) copied most of it verbatim and it's like, fucks sake, it's one package, and half of it is called Nip47XXXX and the rest is NWCXXXX hey, hello? are you in there? NWC is nip-47. the package name is fucking nwc. half the fucking lines of this code are overflowing from all these repeated words. you are breaking my ability to read, bro. fuck you.

people who think dynamic typed languages are easier are not thinking for one second about the lack of safety in this. like, the most common error in javascript is you feed a function some symbol, and it isn't the right type. the IDE can't identify the error so you can type it away freely without knowing you are making an error.

in Go, it will tell you "this symbol is not the correct type".

type matters. just like punctuation. and it saves you from having to put the fucking type name in the fucking variable and function names.

and don't get me started on the byzantine labyrinth of object type hierarchies.

the big problem with especially javascript is because of the lack of typing, errors become a thing like the old saying about children: seen but not heard.

"something went wrong"

out of sight, out of mind.

about 80% of programming work is debugging. anyone see a problem here?

afaik there is a Go library by somebody, check if you fan contribute there.

JS is just more wide used.

JS is not widely used for servers that need to handle high load with low latency. Go's throughput is a bit lower than C/C++/Java/Rust but its latency is way lower.

anyway, i am not turning my relay project into something that requires 50 different toolchains to be installed. linux, bash, go, the end.

that JS library is a client library...

the js-sdk one? no, it has client and server

https://github.com/getAlby/js-sdk/tree/master/src/nwc

i actually didn't notice the client part of it and refactored only the types and wallet service parts first, still gotta finish the client. i need both for completeness, i think the client side would only be needed to make payments outbound, the server would be for receiving them. or maybe i do need both, idk, but i expect to need the client later when i build a UI

btw, why is the encryption functions for the client only doing nip-04?

Maybe this can help. It's an implementation of me hijacking the spec to transfer utxos and other data via nostr for a silent payment thing I've been working on. It's server side code but at least it's GO...

https://github.com/setavenger/blindbit-scan/tree/master/pkg/networking/nwc

looks ok, but i have to meld it with my highly modified fork of go-nostr... i've done the server part, just gotta connect up the client parts and then i'll be able to start building a relay bot that manages subscriptions based on payments

followed you because i haven't got an ear to listen to people who are all in on the Cult of Dev

i'm just wondering also why the client is only doing nip-04 crypto though, now i'm working through the client part. easy enough to change it probably but maybe there is a reason nostr:npub1xv8mzscll8vvy5rsdw7dcqtd2j268a6yupr6gzqh86f2ulhy9kkqmclk3x ?