pull down to refresh

87 sats \ 3 replies \ @k00b 24 Jun \ parent \ on: What are you working on this week? meta

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):

  1. a checkInvoice function for receive side to record if an invoice we generated was paid
  2. a checkPayment function for send side to gather the preimage/status for an invoice we attempted to pay

So as-is:

  • lack of getBalance reports balance as unavailable
  • lack of checkInvoice warns 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 definite fail response, warns that payment status is unknown to us and could be complete/inflight
write
compose
1 sat \ 2 replies \ @justin_shocknet 22h

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_sats would 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_sats you see in a success response may be out of date.
    • Mitigation would be to re-poll for available_sats if 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_sats state is cached to cross clients by SN's service level storage

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.

reply
35 sats \ 1 reply \ @k00b 16h

We implement getBalance as an independent periodic poll to the wallet/node provider/endpoint. Supporting other patterns is not something we'll likely pursue anytime soon. Regardless, at worst, a wallet/provider without a getBalance-like RPC to poll will just show balance unavailable. Not ideal, but also not that bad either.

  • If a user has it set to manual approval, available_sats would show 0, and SN would have to try anyway expecting the user approves the request manually.

We don't gate payment attempts by balance showing a sufficient amount. We attempt payment then process responses very carefully and conservatively (ie to not invite double pays). Balances are for human eyeballs only so that customers can determine in advance if a payment will succeed or not.

reply
91 sats \ 0 replies \ @justin_shocknet 14h

Sounds good, we can just add a shape then for available_sats without an actual debit that you can use to populate UI when you fire getBalance

reply