https://welshman.coracle.social/ saved my life with nip46, which is broken on NDK. I spent a whole day trying to make it work for zapnode.io until I gave up and switched to Welshman.
#orly #devstr #progressreport
so, it took some reading of the nip and examining the code. the names of things was awful.
the spec says that the connect URL contains a *secret* key, and the js-sdk code had named it a public key. it is not a public key. this made the AI confuse the way it wrote the key handling, because further down the NWA client code, it tries to create an NWC client to subscribe to responses and it was trying to create the NWC client with what was labeled a pubkey. lol. uh, no. the NWC server gives a pubkey, and a connection specific secret key for the client to sign with. this is input into the client across a back channel and then is used to sign events such as to request to make a payment, or an invoice, or whatever.
i went over it like 3 times before i referred to the spec and it clearly says:
## Nostr Wallet Connect URI
Communication between the client and wallet service requires two keys in order to encrypt and decrypt messages. The connection URI includes the *secret key of the client* and only the public key of the wallet service.
i think i used a similar design with Indra. the client forwarded two secrets, in fact, and these were the um... what's it called that you get back from a lightning payment... preimage, yes. this is a preimage, but what i specifically was using it for in indra was both to identify the client (by the pubkey, like NWC) as well as the half of the ECDH, so the client would then use this to encrypt, with an ephemeral public key for each packet. the client knew the secret, so what the router node would do is then be able to generate the same secret by identifying the client via the public key in the signature on the onion layer.
or it was something like that. https://github.com/indra-labs/indra - i used this as identifiers for a "micro account" based system that used lightning keysend or AMP (i forget, might have been keysend) and the nodes would advertise their node pubkey, so the client would then be able to generate a payment by picking out a series of hops based on the pubkeys of the routers and then construct a keysend payment and the receiver would not be able to know where it came from, and the preimage would identify the key that would be used to sign/encrypt messages intended for that router.
anyway. i think i got it straightened out, so tomorrow i will be testing this, by making a connection with alby and then seeing if i can get balance and get info and all that read side stuff to be sure i've understood and implemented this correctly.
once i have the client working i can then start on how the relay is going to keep record of the payments and trigger the update of the (private to relay) relay follow list (it will use a protected tag) and then once it is adding and removing clients based on receiving a zap through the NWC connection, i can then start on the "only you can see this" protected tag event kind 1 message, which will be usable with #jumble with its relay feed and "send only to this relay" and even, that will make it possible to implement some kind of slow CLI.
Praise the Lord for our man Cody Tseng and his supreme nostr client.
i'm gonna have to review the indra codebase some time. i'm not going to use NWC with it, but i just want to fully recall the preimage router secret thing and why i had two of them. maybe i can get funds together some day and actually complete that thing. it just needed the lightning integration, mostly, and a client proxy app that triggers the payments. it happens that NWC will let me do that with the keysend function in NWC. so the last piece to make indra work would be just the router->LN node part, and the LN node has to be slightly different in that it would have an additional p2p layer that advertises congestion state information and its pubkey, presumably using a DHT. this was going to be the most difficult part of it. it's fine for lightning payments to fail sometimes, but a proxy router really should be fast at recovering from dead points in paths, and the source routing means that the client can pick dead points, or congested points, and the only solution for that is the client anonymously gets updates of the state of nodes so they report if they are getting hammered.
this was probably also going to be the hardest problem to solve because deliberately congesting the routers was a possible attack, and hard to mitigate if the attacker danced around the network stomping on routers.
but then i thought, hold on, the attacker can't really congest it without paying. so, idk, needs more research
Discussion
i am not a fan of the ndk devs. not the greatest quality
I was also not impressed.
part of the reason why i rewrote so much of go-nostr #golang #nostr SDK was because of what i saw, but also i'd heard about fiatjaf's work with - nostr-tools i think it was. also subpar.
i think these libraries are now adequate but they caused all kinds of problems for client devs over the last 18 months that i was watching. this is also why hodlbod made his libraries and same with hzrd149
the thing that is interesting and i always consider to be a red flag. the more hype around a dev, the less likely they are to be fastidious and diligent. we don't want rockstars for devs, they should be the most irritatingly dry, serious people you can find.