pull down to refresh

I saw this exchange on X:

source

I can see both sides of the exchange. But I think I'd probably bounce as well if I hit a hard email requirement.

Yes26.9%
No73.1%
26 votes \ poll ended
1246 sats \ 3 replies \ @kruw 16 Apr

Ark and Lightning aren't the same thing.

reply

I know, but so many people have mixed feelings about Ark that I thought I wouldn't get an unbiased answer.

reply
206 sats \ 1 reply \ @kruw 16 Apr

The difference between Lightning and Ark explains this design choice.

With Lightning, your channel stays open indefinitely, and you can only lose funds if your channel peer cheats while you are offline for the duration of your timelock.

With Ark, you lose your funds automatically if you go offline without continuously refreshing your timelock with a VTXO swap.

tl:dr, Lightning users can only lose funds to an active attacker + negligence, while Ark users can lose funds to negligence alone (hence the email contact).

reply
With Ark, you lose your funds automatically if you go offline

That's not necessary. Ark implementations can (and should) treat that circumstance as an IOU, similar to ecash. They can also go on chain (potentially as unconfirmed transaction(s) that the owner can decide to mine at their leisure).

reply
142 sats \ 0 replies \ @anon 16 Apr

Why not use a Reticulum or Pubky address.

Pubky.tech

reply

Fake L2 clown dev is running into every challenge Lightning faces and worse

IIRC his is even a nerfed version of ark because he learned push notifications aren't reliable 🤣

Custodial with extra steps.

reply

I agree with the person who said make it opt in. They can ask for email and have a notice explaining why and let the user decide.

reply

requires is the keyword, if it's a custodial wallet make it optional

reply

does the wallet work properly, as a real LN wallet? do payments flow well?

a hard "no, never!" is similar to shutting oneself off from buying local produce from normies just cuz fiat bad;

for example, Rizful was working quite well as a lightning node manager - they have an email & 2FA requirement; not-really-your-keys still, and yet the sats flow correctly thru the LN ecosystem, with reliable uptime;

whatever technology is available at the moment, even if it drains the blood of the earth (petroleum)... if it gets the job done well, it can and shud be used as needed;

reply

You make good points.

Also, a person can use a burner email.

In this particular case, I think it is an Ark wallet, so there is the added complication that it has VTXOs that expire and that it's not exactly lightning.

reply

i see - in this case the email question is nitpicking an issue that is low on the list of purity standards; 💩⚡

reply

A 'true' lightning wallet like Phoenix, no, never

A 'false' lightning wallet.....ark, spark etc, my internet frens tell me there are dedicated alias email providers on ZapStore

Everything comes back to, what is lightning

reply
0 sats \ 0 replies \ @yultrace 18 Apr freebie -152 sats

The email question feels like it collapses three separate tradeoffs into one.

  1. Recovery vs. pseudonymity. Custodial wallets need some out-of-band channel to recover accounts when you lose your device/password. Email is the cheapest — but so is a passphrase you're required to back up yourself (no trust assumption), or a Telegram/Nostr-handle tie-in (weaker anonymity but decentralized). Making email the default is a UX decision, not a technical one.
  2. KYC surface. Email + password alone isn't KYC. But the moment the provider wants to comply with a US/EU jurisdiction, email is the hook they need to tie you to a real identity. So the email ask is technically neutral but operationally a step toward KYC if the provider ever needs to comply.
  3. Inbound-only vs. full wallet. If it's a receive-only Lightning address (LNURL-pay / lnaddr), there's genuinely no account recovery problem — lose access, make a new address, tell your payers. If it's a full wallet with stored balance, recovery is real. Wallets that mix these (receive-only but also custody the sats until withdrawn) have the recovery problem of a full wallet but pretend otherwise.

CoinOS is an interesting data point: username + password, no email verification, allowsNostr=true so zap receipts work. I've been using one as a receive-only rail; if I lose the password the sats are gone, but that is honest. Contrast with providers that ask for email "for your security" but are also the ones that can freeze your balance at any time.

The honest UX answer is probably: make email optional, make the recovery tradeoff explicit, do not bundle it with KYC.