I still insist that these patterns are all backwards
A user concerned with consolidating or budgeting across accounts should do that from their wallet, that gives them a command center with a full view for larger directives than would be in scope for each individual app. It also obviates the online-ness issues.
Persistent LNurl-Withdrawal links is all SN needs for this, right now demo's break after they expire:
Persistent withdraw links understandably need a UX tweak on the SN UI so they aren't accidentally sniped, but a simple warning and reveal click should do it.
We don't want to be a wallet; we don't want to be a custodian (in the long run).
We think you should connect your wallet to SN, not SN to your wallet.
So I think what you have in mind with persistent LNURL-withdrawal links is what actually would push us backwards: being more like a wallet or "source" as it seems to be called in Shockwallet.
Also, I don't see how persistent LNURL-withdrawal links have to be required for what you're showing. Can't you create withdrawals on the fly? If you simply need better API access for that, let us know.
reply
Sad, really sad that you still didn't get what really is Shock Wallet...
reply
What you've done though is exactly the opposite of you're stated objective.... you've now turned SN into a programmable wallet. The aligned pattern would be instead yielding to rules controlled by an independent wallet like ShockWallet.
Custodian labels is theater in this context tbf, it's a trusted budget and invoice transport no matter what you want to project it as- to regulators or otherwise. Getting trapped into narrative corners like that is no way to create better solutions.
The only standard way to withdraw on the fly afaik is a withdrawal link, which expires and therefore breaks after it's been connected. That's already standard you support that doesn't require all the overhead you just implemented to remain a trusted and centralized service