A great lesson on what not to build.
Inspired by nutsack. Being built primarily as a backend component for a Lightning payment system.
Transcript of Brian Armstrong from Coinbase on âfast cheap global payment railsâ (Ethereum).
I wonder if the financial establishment is purposely blind to the payments innovation going on here with #nostr? 
Itâs interesting because over in the mainstream world, everyone seems to be enthralled with âproof of humanityâ as the ultimate solution to trust and the A.I. malaise. Just because youâre human doesnât mean I should like you or trust you. Just because youâre a bot, doesnât mean I shouldnât find you useful. The WoT is a great way to enable nice people and good bots on the terms of whatever the WoT decides to set. The relays are a great start for permissionless WoTs.
All this to say, I am seeing way more creative thinking and solutions here than over there.
This is why I am on #nostr.
Pretty sure a ChatGPT bot generated this, but it is pretty good. nostr:note1ns4p4qg8eejcv7veghhe9008aa4552vg4vh688q9xyea3q3rzgkqr7rres
I'll be speaking about CBDC vs. Bitcoin at @`Lugano Plan âż / @LuganoPlanB (RSS Feed)` Forum, coming up on Oct. 25-26.
Use my code EFRAT for 10% off tickets: https://planb.lugano.ch/planb-forum/
Did you get approval from BIS? đ
Rate limit kind 0, and kind 1 notes for sure. But other kinds might be used for other processes that might have problems with rate limits.
Akshually, Twitter is for government, LinkedIn is for business.
Yep. It's like having a travel wallet you don't worry about losing, because the fund are low and it is easy to replace. I don't expect people to put their life saving into this as there are solutions already.
I don't actually lock the ecash because I store encrypted records. But that could be a great 'multi-sig' option. You need one nsec to access the safebox and another nsec to actually spend the funds.
Anyway, I am just grokking all the new possibilities of this approach!
An npub is a random number with superpowers (encryption and signing)
Yup. That is pretty much the scenario. This is basically how the merchant POS terminals work - they read the random secret emitted by your phone NFC. They know (have confidence) that this number remains in a trusted context (mobile OS, wallet app, acquiring device) and pass this secret to the appropriate token vault provider (the bank or credit card company). They look up the token in the vault, and do whatever is necessary in the trusted context, and return, carry out whatever is needed for the transaction.
In the case of NWC, the trusted context is the client app, holding the secret and sending it to the NWC agent, also operating in the trusted/privileged context on behalf of the user.
Looking abstractly, NWC is exactly the same as payment tokenization. In NWC, instead on using a random secret, it is more powerful to use a random npub for the offline device, because then it gives it the additional power to communicate encrypted matter through a semi-trusted acquiring device that is providing the online communication channel.
I havenât yet had to talk to the manager⌠nostr:npub18ams6ewn5aj2n3wt2qawzglx9mr4nzksxhvrdc4gzrecw7n5tvjqctp424, who is the #nostr manager?
Nostr Wallet Connect (NIP-47) is very similar to payment tokenization that the credit card providers use to put your âcardâ into your phoneâs wallet. All it is is a random secret number in a trusted context (the phone app, the acquiring device) to send to a âvaultâ to get the payment processing information to get authorization.
NWC can do the same, even better. I have implemented NWC as part of my Lightning payment service and quickly realized it could be payment tokenization as well. The device could be completely offline, so long as it is negotiating with an acquiring device that is online, it could do payments. Another advantage is that using the npub, and NIP-44, the acquiring device could mediate encrypted messages that only the offline device can see.
Iâll be experimenting with NWC with #nostr safebox soon. I will need to have an acquiring agent running somewhere, but I see the possibility that the offline device will need very little trust to use this acquiring agent.
More to come. 
testing zaps...
#cashu + #nostr for digital commerce is about as significant as combining rubber and compressed air that revolutionized the transportation industry.
Maybe not 100%, but you can sign, encrypt and make your data redundant by using other relays. Way better than somebodyâs database.
The Triple Crown of your self-sovereignty:
1) Control of your private key (nsec)
2) Control of your data
3) Control of your code (algorithms)
***COOL CONCEPT ALERT***
A digital wallet can exist independently in the #nostr network (see details in linked post below)
The major implication here is that a âdigital walletâ can exist as three separate and independent components: 1) the nsec, 2) the code, and 3) the data. All useless on their own until the nsec holder brings them together into a trusted execution environment of their choice. Further, the data can be replicated to any relay at will, reducing the reliance on any one relay should it become hostile or captured.
IMHO, this is true self-sovereignty- I need no longer rely on any one app, device or service. Also, I believe this invalidates the approach of those âdigital wallet appsâ that the EU and other countries want to regulate on your phone for your âsafetyâ. With this approach, you donât even need a phone, or any device for that matter.
Eventually, someone will create a DVM to provide the trusted execution environment that you need to pay others, prove yourself, and zap anything under sun.
Still in the raw prototype phase, but I have proved to my satisfaction that the concept is valid and feasible. Iâll be working hard to make something usable soon.
All #opensource, of course, and gladly looking for other reference implementations once the functionality and specifications are stabilized and documented.
#unstoppable nostr:note10wuauczvs36sc3st94y9ajexnp46py5em2fuglvrtmkaqfqzruvqq054s0