Yeah I've been thinking about something like this for a couple years now. My first attempt was building something in top of ipfs, but that was kind of a nightmare.
At one point I scraped all of the routes from mountain project, I think I have them somewhere so it's a good "seed" to start something.
Creating a nostr client for climbing seems like the next logical step. Zapping or sending ecash to route developers would be 🔥.
Being able to lock ecash to a relays npub would be awesome.
Relays could charge tiny fees per note processed, and know in an instant that the ecash is valid and has not been double spent.
Fantastic. I'm glad you've made the bare bones typescript server as well. I was going down that path for the cashu file server, but now I may just fork your implementation and add some ecash capabilities on top of it!
You also guarantee that the token hasn't already been spent. An encrypted token may have been sent out multiple people, the p2pk one can only be redeemed at the mint by you.
Just as an example for now. I'm building out this cashu-wallet development kit and wanting to try it out in a lot of different scenarios.
I might try to spin up a more complete version of it though and really put it to the test. I just don't know much about blob storage infrastructure at scale 😅
Imagine being able to pay 1 sat to retrieve an imagine from blob storage.
The micro-est of transactions. Help support either the creator of the content, or the server hosting the file.
All anonymously.
#ecash #cashu
nostr:nevent1qqsqty4k9sllc9e3m0mjwrt0uacpjhpygjkryrhdkwpyudvqvwjkvdcpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzq8m30r240xhza67qjpv7rjgljdq568svnsl69q0ncxa8nj2ee42eqvzqqqqqqy5d4gmp
Imagine being able to pay 1 sat to retrieve an imagine from blob storage.
The micro-est of transactions. Help support either the creator of the content, or the server hosting the file.
All anonymously.
#ecash #cashu
nostr:nevent1qqsqty4k9sllc9e3m0mjwrt0uacpjhpygjkryrhdkwpyudvqvwjkvdcpz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzq8m30r240xhza67qjpv7rjgljdq568svnsl69q0ncxa8nj2ee42eqvzqqqqqqy5d4gmp
You could send it to someone's npub if they're setup on npub.cash
You could bet with it on https://ecash-dice.fly.dev
I'm hoping people will start to build more apps with ecash integrated!
Turns out programmatically buying gift cards is not an easy thing to gain access to. Wish bitrefill would offer an API to purchase gift cards.
Every gift card provider I've found requires a business account, and needs to "review" your application before giving you access.
So much for my ecash -> gift card app idea...
Want to roll dice against a server for a chance to win some ecash? Check out https://ecash-dice.fly.dev
This a POC using the cashu-wallet SDK on both server and client. The server maintains its own cashu wallet with persistence to Redis.
Note: this is super rough right now, don't use any real amounts of sats!
#cashu #ecash
Working on a cashu wallet that aims to be framework agnostic, allowing any website to embed a cashu wallet with ease.
Super early stages right now, feedback and contributions welcome!
https://github.com/ebrakke/cashu-wallet
Do you think client server architecture won't be able to utilize nostr for identity?
I've been thinking about this, and I feel like we have Client Relay architecture (most nostr apps), but there could also be Client Server Relay apps.
If I just want to make an app and host it on a server, but not deal with identity management myself, I could have you sign a nostr event with some challenge and then use a session cookie like a normal client server flow.
I just see it as another way to prove your identity to a server to access authenticated information. I don't think client relay flows will replace every usecase for an app.
What if clients didn't actually deal with signing and publishing your notes?
What if a client could operate in a mode where it just produced the event template, and you scanned it as a QR code on your phone (which holds your nsec) and then your phone published the signed note?
A bit like a PSBT but for a nostr note.
The phone client just knows how to sign + publish notes. You could manage multiple keys there.
Could be used to prove identity as well. A site can just present you with a challenge, and you sign the note on your phone and send it to a relay or API endpoint.
Rather than an oauth like flow (oauth is clunky) it's more of a 2FA flow.
Relying on browser extensions to handle nsec is a terrible experience.
Yeah seems like amber is what I'm thinking. Nip-46 seems needlessly complicated though. You can do so much with it, but the up front setup cost of something like an nsec bunker for the average person is a lot.
It'd be sweet if you could lock up ecash to the commit that closes out a GitHub issue.
Whoever signs the commit that closes the issue could unlock the payment.
Workflow if maintainer is trusted:
1) maintainer creates a GitHub issue
2) maintainer assigns a cashu-address to the issue (maintainer knows SK)
3) bounties accumulate on issue
4) developer does work and closes issue
5) maintainer claims the ecash and redistributes to developer
What if cashu token is revoked? Should the bounty fluctuate? Should maintainer claims the token immediately and essentially "escrow" them?
Is this basically just an escrow file for locked cashu tokens?
Maybe something like this
1) maintainer creates a GitHub issue
2) public key created by maintainer for that issue
3) dev who wants to work on issue "claims" the issue and generates a new key, issue key + dev key (like a multi sig key)
4) cashu-address created from new key to solicit funds to do the work
5) dev does work and merges issue
6) maintainer reveals SK to dev to claim the cashu tokens.
Essentially the dev would wait for tokens to accrue before doing work.
People contributing ecash can revoke the tokens at any time (e.g. maybe another dev comes along who will do it faster)
"Defunct" Tokens will never be claimed unless maintainer + dev collude and the tokens aren't revoked
Oddbean new post about login | logout
Notes by Erik | export