It is important to empathize with frustrated users. It's sometimes an unattainable ideal, but who hasn't hit software that Just Doesn't Work? We don't really care if it's just something about our setup, or fundamentally broken, or a completely unhelpful error message: it's an incredibly frustrating feeling of impotence.
Sure, you shouldn't take it out on the devs you aren't paying, but we're all human.
I can't speak for all developers, but I became a FOSS coder in the Linux Kernel. That gave me a pretty thick skin: Linus could be an ass, and even when he was wrong there was no appeal. So I generally find it easier to sift through the users' frustrations and try to get to the problem they are having.
GitHub
Core Lightning is incompatible with the Lightning Network - lacks support for payments · Issue #7180 · ElementsProject/lightning
I am not sure if it is just me or others also, but I have noticed that ever since updating to version 24 most payments fail. I get alot of these me...
And often it turns out, I agree! This shit should just Work Better!
CLN payments are the example here, and it was never my priority. That might seem weird, but the first production CLN node was the Blockstream store. So we're good at *receiving* payments! But the method of routing and actually making payments is neither spec-defined nor a way to lose money. It's also hard to measure success properly, since it depends on the vagaries of the network at the time
But it's important, turns out :). And now we see it first-hand since we host nodes at Greenlight. So this release, unlike most, was "get a new pay system in place" (hence we will miss our release date, for the first time since we switched to date-based releases). Here's a list of what we did:
1. I was Release Captain. I was next in the rotation anyway, but since this was going to be a weird release I wanted to take responsibility.
2. I wrote a compressor for the current topology snapshot. This lets us check a "known" realistic data set into the repo for CI.
3. I wrote a fake channel daemon, which uses the decompressed topology to simulate the entire network.
4. I pulled the min-cost-flow solver out of renepay into its own general plugin, "askrene". This lets anyone access it, lets @lagrange further enhance it, and makes it easier for custom pay plugins to exist: Michael of Boltz showed how important this is with mpay.
5. A new interface for sending HTLCs, which mirrors the path of payments coming from other nodes. In particular, this handles self-pay (including payments where part is self-pay and part remote!) and blinded path entry natively, just like any other payment.
6. Enhancements and cleanups to our "libplugin" library for built-in plugins, to avoid nasty hacks pay has to do.
7. Finally, a new "xpay" command and plug-in. After all the other work, this was fairly simple. In particular, I chose not to be bound to the current pay API, which is a bit painful in the short term.
8.
@Alex changed our gossip code to be more aggressive: you can't route if you can't see the network well!
Importantly, I haven't closed this issue: we need to see how this works in the Real World! Engineers always love rewriting, but it can actually make things worse as lessons are lost, and workarounds people were using before stop being effective.
But after this fairly Herculean effort, I'm going to need to switch to other things for a while. There are always other things to work on!
