reply on: Have you connected an external wallet on SN? \ stacker news ~meta

1150 sats \ 8 replies \ @ek 27 Feb \ parent \ on: Have you connected an external wallet on SN? meta

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.

37 sats \ 0 replies \ @DarthCoin 29 Apr

Sad, really sad that you still didn't get what really is Shock Wallet...

0 sats \ 6 replies \ @justin_shocknet 27 Feb

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

0 sats \ 5 replies \ @ek 27 Feb

What you've done though is exactly the opposite of you're stated objective....

We're not done yet, this was just the first step of many to come

The only standard way to withdraw on the fly afaik is a withdrawal link, which expires and therefore breaks after it's been connected.

Ah sorry, I didn't mean withdrawal links. I meant you can create an invoice for a service and then let the SN node pay that invoice. It's currently not trivial how to do that without the frontend but it's possible. That's basically a withdrawal where expiration of withdrawal links don't matter and should align with what you're building with your wallet. I don't understand why you would need persistent withdrawal links.

0 sats \ 4 replies \ @justin_shocknet 27 Feb

Leaving programability at the wallet layer is step 1, our nostr account stuff could provide further separation and solve offlineness.

The lnurl-withdrawal link is the only standard way for an external wallet to pass an invoice for the service to pay

512 sats \ 3 replies \ @ek 27 Feb

Mhh, I think we are talking past each other. Are you talking about LUD-14 and maybe LUD-15 when you say "persistent withdrawal links"?

1332 sats \ 2 replies \ @justin_shocknet 27 Feb

Nope, none of that extra stuff is needed,.. straight LUD-03 which you have already is fine.

The balance you see in my screenshot comes from the maxWithdrawable tag in the response, literally the only thing in the way is the timeout of the k1. Fixing this obviates your AUTO-WITHDRAW efforts with the existing neutral spec.

Conversely, LUD-19 could be used for "AUTO-FUND" too if desired, but that's redundant to the user just adding their "stackerwallet" lightning address as a source

659 sats \ 1 reply \ @ek 27 Feb

Mhh, I see now what you are talking about, thanks!

I was confused since LUD-03 mentions that k1 should be ephemeral:

Note that service will withdraw funds to anyone who can provide a valid ephemeral k1.

So aren't "persistent withdrawals links" non-standard behavior? All the other sources in your screenshot, do they accept the same k1 over and over again?

Also, can you elaborate on this part:

so they aren't accidentally sniped

What do you mean with "sniped"?

2205 sats \ 0 replies \ @justin_shocknet 27 Feb

We haven't run into any other expiring K1's yet

Per the spec "k1": string, // Random or non-random string, so it's not opinionated either way

On the subject of sniping, that foot note on the spec is related and @k00b actually mentioned this before too...

When you go to the stacker wallet and click on QR Code, the QR just displays on your screen and contains the k1... any cameras behind you could potentially sweep funds before you do.

The expiring of the k1 is a mitigation for a camera behind you doing a replay attack later.

2 simple ways to fix both problems:

One is to instead of the QR code, provide the LNURL as a clickable link so that only the designated protocol handler can see the k1 parameter.

The other is to keep the QR code, but blur it out and make the user click off a warning to be sure they have privacy first, this would mitigate the existing sniping vulnerability.

Personally I think both would be good.

The flow in ShockWallet, when it gets an LUD03, is it asks the user if they want to sweep the balance... or add it as a source so they can subject it to continued automation in accordance with their trust preferences and budgeting rules.