pull down to refresh
We implement a getBalance function for each send side wallet that supports balance fetching. Ideally we'd be able to use the ndebit string to get a clink balance as an independent request. If it's a field on the debit response, it probably wouldn't make much sense for us because we'd have to cache it clientside and it'd be stale until money was sent again.
To each wallet we are also adding (when supported):
- a
checkInvoicefunction for receive side to record if an invoice we generated was paid - a
checkPaymentfunction for send side to gather the preimage/status for an invoice we attempted to pay
So as-is:
- lack of
getBalancereports balance as unavailable - lack of
checkInvoicewarns that we don't know if the invoice was paid - lack of
checkPayment, assuming we missed the preimage of the send response and did not get a definitefailresponse, warns that payment status is unknown to us and could be complete/inflight
Ideating on this a bit since it's becoming a common request... wanted to run this possible extension by you...
CLINK debits does seem like the obvious place for balance info, but there's a catch...
CLINK debit connections don't necessarily have a balance of their own since debit requests can be either manually approved or have rolling auto-approved budgets that can reset based on time.
We could expose the remaining CLINK Debit budget as something like available_sats, either as added payload with each successful payment response, to a poll, or both.
Two edgecases with that for you:
- If a user has it set to manual approval,
available_satswould show 0, and SN would have to try anyway expecting the user approves the request manually.- Potential mitigation here is instead of showing 0 we flag it as either manual or exhausted
- If a user has it set to auto approve, but blows their budget, the last
availabe_satsyou see in a success response may be out of date.- Mitigation would be to re-poll for
available_satsif the amount is lesser than the forthcoming request.- Users using SN on multiple devices could throw this amount off too, so might need a re-poll anyway unless the
available_satsstate is cached to cross clients by SN's service level storage
- Users using SN on multiple devices could throw this amount off too, so might need a re-poll anyway unless the
- Mitigation would be to re-poll for
Beyond that, a non-CLINK way, would be the SN Client just using the full ShockWallet RPC and becoming another interface for Lightning.Pub. That could get a little heavy on your end given it's nsec based keyring, but does open an interesting design surface.
@Car brought to my attention the new wallet ui... sounds like if we add remaining budget/balance to clink debit responses you could use it as a web wallet from SN? Or would you need it as a info query separate from an operation?
Would be a good spec extension I was marinading on anyway, just don't want to complicate handling for sdk users, let me know what you're thinking is on it...