I truly think there are many parallels. What made me fall in love with wine is its authenticity and scarcity.
Some wines become irreproducible because of a change in fauna, or a change in climate or simply because a winemaker died and had no heirs.
Of course this is not the same cryptographic-secured irreproducibility, but I believe it is the next closest thing.
Building and open source project using an open source library to interface with the open source protocol… and contributing to all of them along the way 💜
npub.cash -> cashu-ts -> Cashu 
I would, but it’s 4200 miles from my place haha
It’s a staging url with a bright yellow warning at the top. I am sure they will be careful 🙃
What an amazing idea. I am sure there is a way to make this work without disclosing your information to the mint prior to the attacker unblinding the token.
Another Cashu-native Lightning Address powered by npub.cash 🤯
This is amazing! 💜 
“json bills” I love this 👏 nostr:note1xrat9xrjc9kpx0gvy3n290768hg4yh0l53vwgclm5n3qs2ylrags0jv8a7
Yes definitely! I am already working on that as an opt-in feature
That defeats the purpose. At some point all proofs in npub.cash should be locked to the users pubkey to minimize the trust required in the server operator
QR codes & token string length. Also overhead on both client and server for things like decoding etc.
I wonder what would be a better way to solve this issue…
npub.cash will hold many many proofs for its users. If someone wants to withdraw, the server needs to send all those proofs over in a big response.
The obvious choice is to run clean up and consolidation jobs that merge proofs together, but once P2PK is adopted this will no longer work (as the server cannot do anything with the proofs)…
I’ll keep thinking about this, but maybe one of you has a bright idea ✌️ nostr:note1gtyyg5p7njtlhvvzj5gp6dxe5tnx46kd7mc5wmrej3psgxrz8cus7m2k99
surprised_pikachu.gif
PSA: npub.cash just had a small change in its public API!
While /claim used to return a token containing all pending proofs, it now returns a token containing max. 100 proofs! Additionally there are two new keys in the payload:
- count: how many proofs are included
- total pending: how many proofs are pending in total for the user
This change makes sure that the token does not get too long for handling it and lets API users now if there are more proofs pending.
I am not perfectly happy with this yet and I will continue looking into other ways to handle these edge cases. 🫡💜
Just read the latest FM newsletter and found this lmao 😂 
It’s called retronasal smell. The tongue is actually pretty “bad” at tasting. It can only differentiate between some macro / major tastes (sweet, sour, etc.). Other aromas that you taste actually come from the nose “smelling” the molecules going back into your nasal passages through your throat.
Its the main reason why sommeliers fear getting a cold / clogged nose 😁
Yes I did. And yes I did. React Native is ALOT slower than native. However:
- Depending on the use case this is actually not an issue
- You can always outsource very heavy-duty work to native modules that run outside the JS thread.
- React Native runs two seperate threads by default; JS and UI. For example a loading spinner can still run smoothly while the JS thread does heavy work in the background.
With Current we pushed an JS only app to the limits. Handling hundreds of nostr events, parsing them and rendering UI components from them really was difficult, but it ran smoothly on most devices.
I would not recommend running POW in a react native app without using native modules
Yes absolutely. There is a PR in the work, but I had to push it back a bit because this was a functional change with high priority. Once this release goes live I will continue and add manual NIP-60 withdrawals first and auto-claiming to NIP-60 wallets soon after.
After being delayed for over a week I finally managed to finish the new release for npub.cash. It is now in staging and if everything goes as planned I will manage to release it tomorrow.
This release took a while to complete, because it changes the way how the server keeps track of the token spending-state. It used to check all pending claims all the time when user accessed the wite, which cause much traffic for mints and also caused issues when users had many proofs pending (Some had over 1000...)
npub.cash will now assume a token as spet as soon as you create the token / qr code. If anything goes wrong, you can resurface the token at any time from your withdrawal-history tab.
Also npub.cash will check how many proofs are pending and will paginate the result if there are too many. This will keep issues from arising, especially regarding token size.
