Yes! I noticed this again when Pablo released Nutsack and it just works with what I have been building for 8 months

Yes

https://web.archive.org/web/20120203215527/http://static.thepiratebay.se/dreamworks_response.txt

Nostr vibes 👏

Turns out I pretty much “bricked” this guy for the time being…

I went through the setup quickly to see the process (I usually do this with all wallets). Then I learned that (as of right now) there is no way to show the seed phrase again. Also there is no way to reset the device…

The result: a hardware wallet that I have no backup for!

Npub.cash Update

It's been just over eight months since I started working on npub.cash, and it's been an incredible journey! During this time, the project has evolved significantly, with its goals and requirements shifting along the way. Originally, npub.cash was designed as a tool for wallet and Nostr client developers, but it has unexpectedly become a popular day-to-day wallet for many users to receive zaps on Nostr. I absolutely love seeing this, but I must admit that the frontend I built was intended as a demo to showcase how the API could be integrated, not as a fully-featured wallet.

Instead of focusing solely on backend development, I spent considerable time trying to adapt the frontend to this new use case, keeping pace with the rapid advancements in the Cashu and Nostr ecosystems. In hindsight, this was a mistake. Npub.cash functions best when integrated into a comprehensive Cashu wallet, as demonstrated by nostr:npub10td4yrp6cl9kmjp9x5yd7r8pm96a5j07lk5mtj2kw39qf8frpt8qm9x2wl and nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg with their integrations in 0xChat and cashu.me. Therefore, I will be reworking the npub.cash frontend to align with its original purpose: providing a solid, minimal showcase integration for developers.

What Does This Mean?

- Removing Lightning Withdrawal Functionality: While paying invoices through Cashu is straightforward, handling change is not. The user experience of this feature has always been suboptimal, and a full Cashu wallet is better suited for it. To pay a lightning invoice with your npub.cash balance, you should withdraw it to a Cashu wallet first.

- Removing Static Payment Pages: This feature was a proof of concept that hasn't seen much use.

- Streamlining the Frontend: Simplifying the frontend to a minimal yet stable demo page will free up time for more important developments.

Priorities Moving Forward

- Server-Level Features: Focus on features like Pay2PublicKey, MultiMint Support, NIP-61 auto-withdrawal, user settings, and more.

- API Overhaul: The API has evolved over time, so it's time to rework all endpoints and publish a v2 of the API.

- Improved Documentation: While there is docs.cashu-address.com, it hasn't been updated in a while. As an API service, npub.cash needs comprehensive and up-to-date documentation.

I am incredibly thankful for all the support I have gotten to this point. Not only for the positive feedback, but also for the supportiveness when something did not work out as planned. We are far from done, and with recent additions to this ecosystem (looking at you nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft) I am sure that there will be so much great stuff coming. Onwards! 💜

npub.cash PSA

Let’s see what you got ✌️

I will look into this! I have not tested amber thoroughly yet

We are back ✌️ nostr:note1qw6zrtqfj8rydx5xe9kelvekngzl5qyrtl4ajleefeh64m06vdaq2vfn8x

Dear npub.cash users,

npub.cash is currently experiencing some issues with all lightning operations. Withdrawals are not affected.

This seems to be caused by a downtime in the Blink API. I will share an update once this has been resolved 💜

It seems like there are issues with the Blink API right now, which npub.cash uses to wrap invoices.

I am looking deeper into this and will give you an update once this has been resolved.

Investigating!

Sorry, I said nut zap but I meant nip-60.

So basically when my app wants to use a logged in users Cashu wallet, but it discovers multiple kind 37375 wallets

Thanks! I es thinking about the case where to wallet is not generated by the app itself, so it wouldn’t know the right “d” tag.

I think it would be good if those tags were chosen by the user and not completely random. In that case a UI could pop up a dialogue for the user to choose the correct wallet

I am working on adding nut-zap withdraws to npub.cash right now.

nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft I think I accidentally created two wallets, and now I got two 37375 events for my pk. Whats the best way to deal with this? Should senders just assume the newest wallet is the right one to send to?

Cannot wait to finally test npub.cash's nip-60 integration 🤫

Life changer: write a tmux setup script and alias it to get your dev environment set up quicker

https://video.nostr.build/5ca02feb3e278b8e2cf1d5cab8efe0bdeed691da81622a75fb25722d6df87cbf.mp4

Sure, but how would the UX flow look like?

Let’s say I have received 50 zaps and want to claim them. I close the token by accident. With the withdrawal list I can resurface the token. How would that work if I see only “deposits”? I guess you could let the user reconstruct a token by selecting certain “ins” but how would they know which ones are really spent and which ones are marked as spent because they closed the token screen?

Maybe it do list both. Adding withdrawals was necessary to avoid people loosing proofs, as npub.cash is now optimistic about it and marks all proofs as spent once you withdraw.

So replacing withdrawals will not be possible, but the history could list both ins and outs

Right. I am definitely talking about high quality, artisan wines that tell a story about a terroir.

Not the cheap, one-fits-all pinot gris from the supermarket