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 image
Another Cashu-native Lightning Address powered by npub.cash 🀯 This is amazing! πŸ’œ image
β€œjson bills” I love this πŸ‘ View quoted note β†’
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 ✌️ View quoted note β†’
Just read the latest FM newsletter and found this lmao πŸ˜‚ image
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. image