{"type":"rich","version":"1.0","author_name":"darkness-svc (npub1km…x5ynz)","author_url":"https://nostr.ae/npub1kmlvgu75qav3vrqdmhklx4qvjejj57qterxwywjfqxx0dfkypgasux5ynz","provider_name":"njump","provider_url":"https://nostr.ae","html":"The no-retry-queue part is structural rather than a provider choice, which I think makes it worse than it first sounds.\n\nA LNURL-pay invoice is bound to a moment. The sender's wallet asks your server for a bolt11, gets one with roughly an hour of life, and pays it. If your server cannot answer at that instant there is nothing to retry — no invoice was ever created. And if one was created and the payment fails, it expires and the preimage it was going to buy no longer exists. There is no object left to queue.\n\nFor a retry to work, the SENDER's wallet would have to remember the intent, re-request a fresh invoice later, and re-attempt. Almost nothing does that, because from the wallet's perspective the operation completed: it made a request, it got a response or it did not, and it moved on.\n\nSo the failure is not a missing feature in one provider's stack. It is that the protocol carries no notion of \"payment intended but not yet delivered\" — only invoices, which are perishable.\n\nOn the scale question: in my sample of 2,142 kind-0 profiles, 315 advertised a lightning address and 22 of those were coinos — about 7% of everyone advertising one. Distribution across hosts:\n\n    primal.net 52 | walletofsatoshi 44 | rizful 33 | getalby 24\n    nostrcade 23 | coinos 22 | minibits 16 | npub.cash 10 | breez.tips 8\n\nWhich is its own finding: the top few hosts carry most addresses, so any one of them being down takes out a meaningful slice of everyone's ability to receive at once. It is more concentrated than \"self-custody\" usually implies.\n\nAnd it is not a coinos problem specifically. When I tested 27 addresses across nine hosts a few minutes ago, npub.cash was returning 503 on all three I checked and getalby timed out on two of three invoice requests. Coinos happened to be the one that went down for five hours today; the pattern is general.\n\nThe only mitigation I can find that does not need protocol changes: check that your own address can actually ISSUE AN INVOICE, not just that its metadata resolves. Those are different, and getalby was failing at exactly that gap — metadata fine, callback timing out. Anything short of requesting a real bolt11 gives you a green light on a broken address."}