pull down to refresh

I'm sorry this is hard to use and hard to keep it working. We know it's difficult to use and have a lot of work left to do. We will make it better.
For context, it's quite a bit more complex than say making a button do something when you press it. We are coordinating a payment between multiple computers we don't control. Our goal is to get it close to button-press-like easiness in terms of your experience, but it's going to take us time, lots of fucking work, and experimentation to hide and communicate that complexity.
This thing is a Model T right now - you crank it, press 2 buttons, 3 switches, blow in a tube, pray, then maybe it gets you where you're going. It'll get better faster than a model T did because it's software, but a lot of what we're doing is new.
Also, your complaining helps a lot so please keep it up. I struggle with how angry you sound sometimes but that's on me. Most people in your shoes would've given up. Props to you!
My zaps fail only rarely -- when they do, the logs report something about routing fees are too high. When I retry, it has always worked. I don't actually change anything about my setup -- I wouldn't know how to do more than add another channel, and the channel I have goes to a pretty fat LN pipe.
I know ya'll have no shortage of stuff to do, but it would really be illustrative to know what's happening on the backend, how you're iterating and evolving things, etc. I feel like this pragmatic guide to using LN in real life is totally dark territory. Could you an @ek do a podcast every couple weeks or something?
If I was in Austin I'd do a documentary on ya'll.
reply
The only time my zaps fail is when I have a problem on my end. Usually lost internet connection or my computer that runs my wallet restarted.
I highly recommend everyone who wants to use Stacker News with an attached wallet to use a self-custodial lightning wallet with a direct channel. You will not pay any routing fees and you will have a consistent, reliable experience.
reply
I highly recommend everyone who wants to use Stacker News with an attached wallet to use a self-custodial lightning wallet with a direct channel. You will not pay any routing fees and you will have a consistent, reliable experience.
I may have spoken too soon, lol.
Last night my computer restarted and when I reopened Alby, I reopened the wallet, but the NWC connection to SN couldn't get re-established. I ultimately had to delete the old NWC connection and start a new one.
I'm curious as to why that might be. The wallet logs didn't show any routing errors or anything, just timeouts on sending/receiving payments.
reply
100 sats \ 5 replies \ @k00b 15 Jan
I've noticed after prior updates to Alby Hub my NWC strings are all invalidated. I think it might be a symptom of Alby Hub being kind of new and them correcting mistakes they made with our older NWC strings when we update. I hope this won't always be the case.
I'm curious as to why that might be. The wallet logs didn't show any routing errors or anything, just timeouts on sending/receiving payments.
NWC strings are doing two things:
  1. giving us permission to do stuff on your node
  2. telling us how to communicate with your node to do that permitted stuff
So, when an NWC string goes bad, it either has to do with those permissions going bad, ie being revoked or expiring, or the way we've been instructed to communicate with your node changing or not working.
Routing and fees are in another layer, let's call it The Lightning Layer, and The NWC Layer sits on top of it doing the things I mentioned above. If The NWC Layer goes bad, it means we can't communicate with The Lightning Layer, and the only indication we have that that's happening is The NWC Layer ignores us and we timeout.
reply
Ok, then I'm reasonably sure the error was related to NWC strings and not Lightning.
What I don't quite understand is that the wallet was working right up til last night. My computer restarted after I went to bed, and it wasn't working after restarting the wallet in the morning. It started working again after I downloaded the new Alby update, deleting my old NWC ones, and making new ones.
reply
30 sats \ 3 replies \ @k00b 15 Jan
Restarting must have invalidate the NWC strings on Alby Hub's end.
The NWC connection isn't persistent or anything, so it wouldn't affect our end. On our end, if you give us an NWC string, whether good or bad, all we can do is sign messages with it and publish them to the relay specified then wait for responses.
Timeouts usually happen when responses don't come back, and responses don't come back when Alby considers the NWC string invalid afaik.
reply
So I guess I'm wondering if/where/when an Alby server sits between my computer and Stacker News?
Because I was running the same version of the Alby software on my computer as the night before, with the same NWC strings that failed in the morning. That shouldn't happen unless restarting somehow changed something on an Alby server somewhere, right?
Edit: Sorry, I know this is probably more a question for Alby. But I'm not really sure how NWC works, so this is all educational to me.
reply
500 sats \ 1 reply \ @k00b 15 Jan
Hmm I'm sure Alby has an explainer somewhere on how NWC works, but here's mine:
  1. Basically, Alby runs a nostr relay - a server with a public ip and a generic API for sending and receiving messages.
  2. When your Hub creates an NWC string, they generate a private key and associate it with the permissions to your lightning node that you specify.
  3. Your NWC string gives SN, or anyone you give the NWC string to, this private key.
  4. Hub listens for encrypted notes sent to Alby's relay where this public/private key is the recipient.
  5. If SN wants an invoice from you, it sends a message signed/encrypted with this private key to alby's relay, then listens for the result.
  6. Your hub, listening, sees the message, and checks if the bearer of that private key has permission to do the requested action.
  7. If it does, Hub performs the requested action, encrypts the result, then sends it to Alby's relay.
  8. SN, listening, now has the invoice it requested.

That shouldn't happen unless restarting somehow changed something on an Alby server somewhere, right?
Restarting more likely changed something on your computer, but it shouldn't have absent a bug or some reason only alby would know. I can't make sense of it.
I have a channel to SN and some inbound I bought from @Rizful (link) which I recommend for learning tons about using / managing an LN node, either their cloud one or their awesome tutorial on setting up your own LND w/ Docker.
reply
Curious as to why you'd get routing fee errors then, if you have a direct channel.
reply
My guess is that since the whole point of this is that SN is not the custodian, and since other people don't necessarily have a channel open to SN, that it's something to do with that leg of things. If it were just me > SN > them via direct channels it would probably be fine.
reply
108 sats \ 7 replies \ @k00b 15 Jan
Ah, by the sounds of it your direct channel probably gets depleted of inbound sometimes, so we go through the channel you bought (which has fees unlike your direct channel).
reply
I just checked logs -- here's an example.
I think this is somebody trying to zap me, right? My channel to SN has 29k inbound; my other channel has 2.4m inbound. My midwit understanding is that
a) they tried to zap me b) they don't have a channel to SN c) the route to me someplace has fees that fail
Would love to be corrected on this one.
reply
108 sats \ 3 replies \ @k00b 15 Jan
I think this is somebody trying to zap me, right?
Yep.
My channel to SN has 29k inbound
Depending on the size of that channel, your 29k inbound might be reserved for the penalty tx and is unusable.
a) they tried to zap me
Yes.
b) they don't have a channel to SN
Actually, SN is estimating that trying to route you 21 sats with a maximum 3% fee, from SN's node, is not possible. You should see small zaps fail in this way more commonly than large zaps.
(If that 29k inbound is usable, our estimation might not be returning the lower bound wrt routing fees and this is a bug.)
c) the route to me someplace has fees that fail
Understanding how zaps on SN work might help some. They work like lnproxy does. We request an invoice from your node, then "wrap it" in an invoice to our node, then serve that to the sender. The sender pays that invoice by pushing bitcoin in its channels to SN, bitcoin that SN cannot claim that without paying your invoice first. SN then pays your invoice which allows us to claim the bitcoin the sender pushed to us.
So, for a zap to work the sender needs a route to SN with enough liquidity and the receiver needs a route from SN with enough liquidity.
It's built this way so that SN can take its sybil fee, verify that a payment actually happened, and that money actually changed hands. Importantly, SN cannot be paid unless you are paid first, and SN never has custody of the sender's money promising to give it to you. SN is doing exactly what a lightning routing node does wrt custody but in the application layer so we can couple the routed bitcoin to posts and comments. Also, by wrapping the invoice, the sender doesn't know the receiving node's pubkey - the sender only sees SN's pubkey - so we are fixing a lightning privacy issue in the process. confetti
Back to the error message. Before SN requests an invoice from your node for 21 sats (which is 70% of the 30 sat zap), we estimate if we can send you 21 sats with a maximum fee of 3% of zap amount (900 millisats). We estimate that it'll cost 1043 millisats to route you 21 sats, so we have the sender give you CCs instead of paying your node.
Except the ones I notice are when my zaps to others don't go through; and then I retry later, and they do. Wouldn't that mean it's the other person's channels that are the culprit?
reply
Wouldn't that mean it's the other person's channels that are the culprit?
Usually, yes. If you are the sender, there's a failure, and you have enough liquidity to SN's node and your sending wallet is working well, it usually indicates the receiver's wallet had a problem receiving the zap.
We have a PR for automatic retries pending review which should drastically reduce your exposure to these intermittent failures that aren't your fault.
Appreciate it, sir. You keep on doing your thing and I keep doing mine (complaining, venting) and we'll both end up someplace good!
Also love this
This thing is a Model T right now - you crank it, press 2 buttons, 3 switches, blow in a tube, pray, then maybe it gets you where you're going
reply