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](https://stacker.news/items/1528021/r/optimism?commentId=1528060), 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.

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

BlokchainB

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

, 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

. For example, the issue Undisc was pointing to in this thread is a 

 in Alby Hub, where they no longer accept pure spec msats, but made a new custom rule. My guess is 

 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.

Stacker Saloon

saloon

> 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](https://github.com/getAlby/hub/commit/64afc2227f128cf4cd90daf0d844af48e3513166) in Alby Hub, where they no longer accept pure spec msats, but made a new custom rule. My guess is [to support bArk](https://gitlab.com/ark-bitcoin/bark/-/blob/master/server/src/database/ln/model.rs?ref_type=heads#L182-L185) 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.