"Cash is King!", so they say...
With #nostr, the wallet is the network.
#nostoppingthistrain nostr:note19vcx8qd8p0ynwae3507rl7suc2zp0jx2ayvgt7w73hg0kv07y4pq4kdmqm
Fair point. We’re experimenting with new concepts here, so the terminology might now be 100% so we need to iterate. In the mainstream context this would be called ‘data portability’, another great concept, but mostly used in lip service without empowering the user. This is the first instance where I see the possibility of keeping data private on behalf of a user, and where they are independently empowered to remove at any time. If find this very exciting and a complete game-changer for service providers that need to provide some custodial service but with creating a big breachable honeypot.
- Proof of work was invented to prevent spam.
- Satoshi used PoW to rate-limit block production.
- Blocks create scarce Satoshis.
- Cashu puts Satoshis into bearer ecash tokens.
- KeyChat (privacy messenger) uses Cashu tokens as stamps to prevent spam.
Full circle nostr:npub1qg8j6gdwpxlntlxlkew7eu283wzx7hmj32esch42hntdpqdgrslqv024kw.
I love this idea of using ecash as message stamps. This idea has huge potential for drawing value into the digital ecosystem versus the more scary idea of using ecash as an alternative currency.
Remember, proof of work was invented by Cynthia Dwork in 1993 to fight spam and used by Adam Back for honest digital currency.
Message stamps build on these developments and are now possible with Cashu and Lightning. nostr:note1kta54vdhagauvp3gvyur350g7x804y04kyphefn8up7wf4veg4fqj8cm2p
Agree. But that risk can be mitigated by using multiple mints and the ability to clear out to Lightning at a moment’s note. Also, by separating the mint operator from the service provider, it further mitigates a single point of failure risk.
In the end, this architecture makes a mint like a money router - if one goes down, you can easily switch. Finally there are some neat reputation services appearing like bitcoinmints.com and nostr.watch that’s where I discovered reliable relays and mints that I can use.
Sooner or later, an organization will stake their reputation on running a reliable mint and/or relay. When that time comes, we’ll be able to manage our risks accordingly.
If anything, it mitigates risks that are beyond the custodian’s control, like having their infrastructure rugged.
Which specific custodial risk are you referring to?
Currently for the service I built, I have a custodial wallet for each user where I store the privat data in my own database. With this new component, I plan to push all that private data encrypted out to relays with reference to mints and blossom servers. So the only thing I ‘custody’ is the nsec of that wallet instance I am holding that nsec on behalf of that user who ‘trusts’ me. . I will let the user have access to that nsec, if they want it, and if they begin to distrust me, they can sweep the wallet without my permission.
As well, I am no longer storing any unencrypted personal data in my database server so that eliminates a big honeypot risk for me. As for availability, storing on redundant relay servers, is a big plus too.
The beauty of an #nsac is that you can create one for custodial purposes and if you are suspicious of the custodian, you can sweep out the #nsac before they rug you.
This is the unilateral exit option we’re looking for. 👀
I love #nutsack but it was too visual for my liking. Researching the word ‘sac’ revealed that it was the perfect (and more general) concept, hence #nsac. FWIW, I already have a prototype implemented and it is working with a mint and multiple relays. I am sending and receiving lightning payments via a cli that I have built. I am using parameterized replaceable events to store persistent and state information. All working like a charm so far.
Algos for sale to do what you need is a way better idea than having your data rented out to an algo. nostr:note1k5mfgg9lgu6ptlcgwdyhenanvm2twzf97xmanjv8gwp6uraep60s857v5r
NIP-60+61 are being implemented left and right. Love to see it 🔥🔥🔥🔥
nostr:npub1q6mcr8tlr3l4gus3sfnw6772s7zae6hqncmw5wj27ejud5wcxf7q0nx7d5 is a beast, and very clear thinker; can’t wait to see what this implementation unlocks
nostr:note1e93ac62e98l8qrlf4nc749u2hy4gzdat808fhvne2aygkvprruxs02gdgr
Thanks for this. The innovation in NIP-60+61 has put me onto an entirely new path of thinking. Grateful for this! ❤️❤️❤️
I like this simple mental model for #nostr:
#npub is your #nostr public key
#nsec is your #nostr private key
#nsac is your #nostr private wallet
The last one, #nsac, the kernel of the idea is taken from NIP-60/60 by nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft , but can be generalized to hold more types of private information than just tokens.
The genesis of any #nsac is an #nsec - you can use your own, but not recommended- just generate an #nsac for which you, and only you know the corresponding #nsec
The cool thing is that an #nsac can be instantiated across multiple relays and take advantage of multiple providers such as mint and blossom servers.
I am already implementing a Python component called ‘safebox’ which is experimenting with the #nsac concept. It is solving some problems regarding custody - I will get into that in a later post.
All I want is someone to control the NIP numbers.
If you realize that #nostr today is like the early days of refrigeration and air conditioning then you'll be in it for the long haul.
