pull down to refresh

I agree it’s been very unstable.

I was looking at wallets and for the first time I am acknowledging how much of an issue this wallet thing really is.

All the options to send use NWC except three. LND uses LNC (which never worked for me) , Blink uses an API , and Core LN appears to use an RPC?

I see why Darth and others just use CCs once NWC goes down SN become hard to use.

Very frustrating. I'm not going to quit yet. I tried a CLN connection a long time ago, but I kept getting rune errors and probably lost patience too soon. I had LND working through LNC, which I use in another application. The only problem is that with any temporary server issues or LND issues the connection is broken, and lightning terminal needs to be restarted.

reply

Indeed it is! I see why k00b has spent so much time on this. For this site to have any real chance of sustainable growth and retention the wallet item has to be solved. I feel helpless when NWC goes down. I thought my backups would work with Shocknet and LND but nope they fail as well. So I have to resort to CCs

reply
I feel helpless when NWC goes down

NWC is a protocol, it doesn't really "go down". On the application layer, the things that can go down and malfunction:

  1. The "wallet" lightning node where your sats are at
  2. The NWC wallet-side software that makes invoices and sends sats through the lightning node
  3. The nostr relay that receives and makes available NWC messages to subscribers/queries
  4. The NWC app-side software that requests invoices and payments
  5. The app that connects NWC, like SN
  6. In SN's case, SN's LND that wraps the invoice
  7. There being a path with actual liquidity

And often 2x here for 1 to 3 because sender->SN->receiver, though luckily there are good fallbacks on receiver side errors so you don't often see this. I could draw you a flowchart but it'd just give everyone eye pain.

To my memory (I didn't take notes) I've in 19 months thus far only seen 3 or so issues that were truly SN-side issues. Nearly everything else, multiple times per week, was related to item 1 or 2[1]. For example, the issue Undisc was pointing to in this thread is a breaking change in Alby Hub, where they no longer accept pure spec msats, but made a new custom rule. My guess is to support bArk and if my suspicion is correct, then y'all better listen to Darth a bit closer when he goes on a purity crusade next time, because Alby making a breaking, out-of-spec restrictive change to NWC across ALL backends just to support bArk's limitations at the direct cost of pure LN functionality is how your installed stack gets enshittified. You get useless bells and whistles at the cost of reliability and interoperability.

  1. This really speaks for the SN team fwiw - I've worked with at least a 100 dev teams through the decades and this is a great tiny team, they're very involved.

reply

You sir are a SN treasure! So this is mainly an Alby issue not a NWC issue

reply
197 sats \ 1 reply \ @optimism 20 Jul

Haha thanks. I'm not nearly contributing close to what I intend to contribute. I'm no-joke struggling to be of true value to SN and the community here, also because not just the LN/nostr ecosystem, but frankly the web ecosystem has severe issues that are no fun when your background is secure (financial) systems engineering. It'll come though, eventually.

In the case of Undisc's report (and if you saw that same "the amount must be a whole number of satoshis" error, you too) is indeed caused on the Alby Hub side (which is why I didn't have any problems; I don't use Alby Hub rn) and has been nuked out of existence by k00b a couple of hours ago. It's sad that per the decision tree, the only 2 protocols implemented by SN that remain guaranteed to support msats are the LND and LNC baked-in RPC with macaroons/runes. That's not cool.

reply

Ahh I see! LNC didn’t work with me. But this is really good information. I need a NWC back up that isn’t through Alby it appears.

reply

I've never used cc's intentionally before. Will they automatically be accessed if you disable all your wallets?

reply

If you disable your wallets, then you'll receive all zaps as credits. If you try to zap a larger amount than the credits you have, an invoice will be generated for you to pay.

reply

Which makes it hard to bank them for when you need them. I wish I could just bank all my CCs to a certain threshold (3k or 5k) then use sats for everything. Once I see my CC balance being used then I know I have wallet issues.

reply

phoenixd uses an API key (not that this is much easier) and there's shock wallet and CLINK. But your point stands, I think: there is a lot of NWC.

From my non-dev perspective, Lightning in general doesn't make it easy to give an app (like SN) the ability to pull payments.

reply

CLINK Debits solve the pull friction to the extent possible on SN, unfortunately SN doesn't leverage a service key given the client-side nature of it's wallet connector, which adds an extra step... but still 1 or 2 steps less than NWC.

reply

Is that why my send won’t work on here?

reply

No, sending still works fine, but there's an SN quirk where if you add it on one device it wont work on the other device unless you unlock it on the other... SN keeps connection details client side encrypted

Is the issue on one device not the other? If not can try and diagnose from logs

reply

Yeah it’s only on one device. I even tried a test txn while watching the log in my terminal and saw nothing. But when I tested receive I saw the test action in the terminal.

I tired to delete the string and re add it but SN wouldn’t let me paste on my phone just kept showing me auto fill option on the text field to post the shocknet string to send payments.

reply

this is just the beginning. The 2 forks are coming and will be even more mess into having a meaningless zap of 20 sats failing.
See the post I shared today.
Even a direct channel with SN node will be useless.

reply
Even a direct channel with SN node will be useless.

Until k00b would tell us (in advance of course) that SN plans to switch to a BIP-110 client, then it should be fine to have that direct channel open because you'll share the same chaintip, barring any bugs but that can happen at any time. I asked a while ago: #1266146

As long as you run the same on-chain client as your counterparty, you ought to be ok. The big issue, as also the post you shared points out is operators you cannot trust. In times like these, you can be fucked, but you can keep your channels with those that aren't out to fuck you.

I closed 1 channel because it was anyway depleted and I didn't want to bother finding contacts for the operator.

reply

keep in mind that SN node use the LN proxy and act as a proxy.
Direct payment to SN node is not the problem. the problem is when SN node start proxying that zap.

reply

Someone could get rekt on the path, this is true.

If you're running some activist consensus program in a bid to change the network, and then you get bitten, then you'll likely get what you deserve. If you didn't check with your counterparty whether they are above type of hipster activist... you may get what you deserve too.

reply

This might be a long shot, but I do notice that the damus relay is down, and @jb55 has threatened to pull the plug on it soon. I don't know if he's made any announcement yet. I can't find it on nostr.

reply