Nostr Web Client

#orly #devstr #progressreport

so i made a partially working #NWC client, and now i have teh problem that to test notifications, and additionally, other methods, i actually need to implement the wallet service as well, at least the API for it, so i can make a mock to finish implementing it correctly.

i had the AI build out a little CLI and it works for methods that have no parameters, but only get_info and get_balance - list_transactions doesn't work, and i know for sure it's not implemented correctly, because when i run this method on my alby wallet service using a connection URI it doesn't catch the response.

i mean, i know, from endless experience that you always have to implement codecs and APIs as pairs... encoder needs a decoder to test. client needs a server to test.

i just dipped my toes in the pool of the Go code in the alby hub, and it's awful, i mean truly awful, Java-like implementation, with types and methods strewn among dozens of files and as well, a few folders.

this is not how you do things in #golang idiom. you put the types in one file, the methods in another file, and the helpers in a third section.

if you don't do this, it's hard to tell if you even have covered all of the bases. i'd guess that the AI will struggle to make sense out of it too since it has to have such a large context to enumerate all the parts properly.

every time people use foreign language idioms in Go code, God kills a kitten.

these heartless murderers...

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

i'm taking a shortcut with this. since the methods are enumerated and the parameters for request and response are already defined by the client, all it has to do is make the other side of it for me, and write a test

so, i'm getting junie to build something and write tests based on a mock

hopefully it doesn't make it to awful that i can clean it up and then get it to write a series of test calls for the CLI client that verify that the mock does indeed correctly behave like a wallet service and return reasonable fake data that the client correctly prints

might take me a while to get this all correct, but i sure as fuck am not using the pig ugly code in the alby hub NWC wallet service implementation.

even the AI is writing better code than this abomination that alby uses.

i can see where their slow progress with the hub is coming from now. whoever they hired to do the Go services on it is not a go programmer. they are a java programmer writing in Go.

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

well, this is maybe going to actually work. it's taking quite a while for junie to generate and correct all the code, but i will have a generic mock server and probably i will just make it write a test script that spawns a localhost only, no auth relay to act as the relay between the wallet service and the CLI client.

i think once i see the CLI getting results back for every query as expected that i'll know the client is working. it just required building out the whole thing. there's more than just a client in this... there is the server API and all the damn tests of everyfucking thing, and the script to test the CLI against the mock, it's created 4 new source files and to be honest, claude is not terrible at doing this work.

idk if i'll get this all done tonight but maybe... haha... probably also need junie to actually write a series of calls to test all the capabilities for me so i can just throw them at the read-only connection i have with my alby hub and i'll leave it at "read side works" for today.

something else nice about this is that the AI is actually adapting its output to almost match the idiom i use in my code. enough that it doesn't take me that long to clean it up so i am happy with it.

maybe i can find somewhere a mock LN server that can actually do the pretend write side things as well

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

at this point i really only need the read side, so it might be an exercise for later. just to have everything stubbed and mostly correct to the point where i can at least write this actual subscription manager client and it receives the payment notifications that trigger activating subscriptions. really, the complete wallet service/client stuff is just being thorough so later on when i need more functionality i've got a solid base to build off