that's my main issue with cashu, is that it's just too complicated for the average person. but i think we can solve this with time and a better UX. in fact, i know we will.

I'm sure the @routstr guys are happy about constructive feedback

Show me an equivalent UI that is clean and easy for users to understand

I didn't understand what your problem was

minibits walet, works with NWC

i.e. skill issue

cherry on top View quoted note →

I have four wallets: - Onchain onramp (strike) - Lightning (alby) - Cashu balance in routstr - Token balance for an api key It's like 2 or 3 too many

Plus the fiat wallet in your pocket.

I also have like 6 bank accounts

what part did you find most confusing? which wallet? cashu is a protocol.

These are all obviously much better, but unless all wallets seamlessly support onchain, the various flavors of lightning, and cashu, you're always going to have friction when sending/receiving. "scan what?" "receive what?" "what kind of qr code is this?" "oh, my phone doesn't support NFC" "my wallet doesn't do onchain, can you send me a lightning invoice?" "it's saying something about liquidity" "what's a 'mint'?" "what is a 'melt'?" "what is a 'submarine swap'?" "why do I need to 'topup', can't I just transfer funds from my bank?" None of these problems are impossible to solve individually, but solving all of them across a network of apps created by people with different ideas is combinatorially difficult. In nostr we say "don't overload kinds". I think this is the problem — we've overloaded the term "pay with bitcoin". It means: - P2PKH - P2SH - Native SegWit - Taproot - Bolt11 invoice - LNURL - Lightning address - Bolt12 invoice - Keysend - Cashu eCash - Fedimint eCash - Spark - Ark I'm not saying each of these doesn't have its use case, or that innovation isn't good, but this complexity comes at a cost, which either the wallet developer or the user has to bear.

I have probably 20+, this example was just for illustration

And one way to cope is to advocate for dropping support for certain options

none of that is necessary. we all support lightning. you're confusing the complexity you face as a developer playing with bitcoin with what you present to your user. there is so much more complexity you haven't even mentioned. understanding lightning requires reading literally an entire book worth of information (mastering lightning). cashu is 10000x simpler than lightning. your job as a dev is to strip away the complexity and make it accessible. NWC is cool, has nothing to do with cashu, you can use cashu wallets for NWC sources. I'm not going to try to convince you, you do you. fact remains: you find routstr UI complex, cool. none of that has to do with the fact that easy UX is possible when implemented correctly, see the dozens of examples I showed you.

I have 100 and yet we seem to be able to build wallets that a literal grandma can use who has never used bitcoin before.

oh and. complexity is going to increase in the future. more protocols coming.

Things are getting out of hand fast 🤣

Mint selection is very foreign to people. I don't mind this, I personally understand it and don't have issues, however I feel that having to explain this to users is the hard part. Perhaps I need better materials or explanations.

you can use l402 if it is more useful

Easy UX != simple UI, it means things "just work". Do all 100 wallets interoperate seamlessly with the other 100 (10k combinations)? Certainly not. That's my point — not that routstr didn't work (it did), but that it's crufty UI reveals the underlying complexity that leads to poor UX. We can agree to disagree, I don't expect to convince you. But I do think you need to take this problem seriously in order for cashu to succeed (and I think you do, you just seem to treat people bringing this up dismissively, which is weird).

another standard with partial support, neat

yes they do

give me an example of one thing in the universe with universal support

sure

that's not the point, this is:

that's exactly the point because the world you want can't exist

We are almost done with a beta version of Routstr SDK (https://github.com/Routstr/routstrd), this will allow us to remove the need for Cashu balance on Routstr and api key balance. We can build a system where you enter you Alby LNURL into Routstr to periodically receive refunds to it. And when needed it'll automatically pull from your NWC. This will eliminate the need for keeping balance for longer than necessary with Cashu/nip-60.

Sounds great! Another feature request is to add api request history somewhere. On opencode I spent $20 very quickly and it was really helpful for figuring out exactly which API calls caused it. Including number of tokens in/out, dollar amount of upstream, and payment amount would be awesome. Also, I've noticed that the current tally of dollar amount doesn't show in opencode like it does for other providers.

first mistake was trying to do business with @calle