pull down to refresh
169 sats \ 8 replies \ @k00b 23h \ on: Stacker Saloon
Even if we implement all wallet options, I'm not sure this is what anyone wants longterm. We either need:
- one option, that's ubiquitous across wallets/implementations, for both send and receive, that's one click to configure (oauth for wallets)
- e.g. bolt12 (recv) + boltXX (for send)
- every lightning app with a built-in self-custody/trustodial wallet (aka breez nodeless, greenlight, or spark)
Regardless of (1) or (2), the majority of apps with either:
- go custodial and KYC
- use ecash if they ever figure out a way to avoid shotgun KYCing and rugging people to death
None of this scales most likely (ie no one wants any of the above longterm either ... although (1) is the freest of them all, mirror mirror). So really, we need de minimus exemptions to AML/MTL for custodianship if bitcoin apps are going to be a take-over-the-world thing imo.
SN will effectively try to do all four, all optional, to the extent that we can, in the meantime. lol
This new release will be even more confusing... There's an high chance users will get lost between all the wallet options provided, plus the dilemma in sending vs receiving... Wallet page could start with something like this: two setups,
- select SEND or RECEIVE click attach first and then show only the available wallet for each.. seeing the message sending not supported isn't ideal
End up with something like this first
then allow stackers to add backups wallets for each option
reply
reply
reply
reply
yep, only a generation or so from now lol.
most lightning app devs seem to be betting on, as is, flawed custodial solutions in the meantime. i just don't see those solutions producing products I would use. so, I'm hoping the first (1) and (2) come sooner than later.
the simplest solution for us would be to drop p2p zapping all together and just make all sat earning happen via rewards and territory revenue ... but i don't want that product future either.
reply