Avatar
Egge
ddf03aca85ade039e6742d5bef3df352df199d0d31e22b9858e7eda85cb3bbbe
Building https://npub.cash 🥜 Working on awesome nostr, cashu and Lightning stuff 💜⚡️

nostr:npub1xdtducdnjerex88gkg2qk2atsdlqsyxqaag4h05jmcpyspqt30wscmntxy nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft what is the best practice for parsing NIP-46 bunker strings on the web? I just noticed that JavaScript's URL API is not usable, as Safari and Chrome will create wildly different results.

Thanks! Once you figure out how it works it’s a breeze to implement. nsec.app makes it an absolutely amazing experience! Good job!

NIP-46 integration is going great 🔥

The update should be live by Wednesday 💜

https://video.nostr.build/a171ab614dc8213737056d38f5123da82a3552404890ce577fd32a923f35f88e.mp4

NIP-46 support is coming to npub.cash 🔥

I am finishing up the JavaScript SDK and once that is done, it will be implemented on the website, as well as the CLI tool.

Here is a quick and dirty browser demo using the absolutely amazing nsec.app signer. cc nostr:npub1xdtducdnjerex88gkg2qk2atsdlqsyxqaag4h05jmcpyspqt30wscmntxy 💜

https://video.nostr.build/17ef4ec79eeea881cd4dd5e0a3d723cce7bb5db5be8054ca49cf91e16343bf39.mp4

Not including the requests e-tag in the response is a huge missed opportunity IMO

Yes I noticed. I was able to integrate it into my SDK and successfully requested my Cashu-address balance using nsec.app 👏 great work btw…

However request-id is the random string from my request, not an event id right?

I want to build a set of asynchronous functions that send a request and then resolve once I get the response, but from what I can tell there is no way to subscribe to ONLY the response, because the response does not include the requests e-tag, right?

Working on this now 🤙

I read through the spec and I think it’s truely a missed opportunity that a remote signer response does not reference the requests ID. Did you add that to your implementation by any chance?

GM and PV

💜

I don’t keep anything on exchange accounts. I try to stack in a way that does not create too many small UTXOs (~200k) and immediately withdraw to a hot Sparrow wallet.

Then I consolidate using Whirlpool, into mostly 1M chunks and send to cold storage

Sounds cool! Will tinker on this for https://npub.cash

However I think it should periodically fetch your relay list and cache it, so it doesn’t need to do the work at request time

Replying to Avatar Shawn

Sounds absolutely logical to me. 🤙

Nostr is a giant shit show. The fact that our software interoperates at all is a miracle and probably just a temporary anomaly. Given enough time, the relentless breaking changes being made to published NIPs will eventually break everything.

Linux succeeded because "WE DO NOT BREAK USERSPACE". For nostr to succeed, changes must "NOT BREAK EXISTING IMPLEMENTATIONS". There shouldn't be any exceptions to that EVEN IF THE IMPLEMENTATION WAS NON-COMPLIANT.

Pay close attention to Linus right here:

> Are you saying that pulseaudio is entering on some weird loop if the

> returned value is not -EINVAL? That seems a bug at pulseaudio.

Mauro, SHUT THE FUCK UP!

It's a bug alright - in the kernel. How long have you been a

maintainer? And you *still* haven't learnt the first rule of kernel

maintenance?

If a change results in user programs breaking, it's a bug in the

kernel. We never EVER blame the user programs. How hard can this be to

understand?

Linus doesn't want to break pulseaudio EVEN THOUGH pulseaudio was doing the wrong thing.

It seems like every week I find a NIP that I've coded for has changed. This last week I think it happened three times already. Sometimes it's a small change and I quickly update my code. But I can't read all the PRs, and I'm afraid dozens of small changes have slipped past my notice. Gossip is probably now incompatible with multiple other implementations which happen to have implemented different versions of the same NIPs (some older, some newer).

Even if we didn't have any breaking changes, the simple fact that different software implements different optional NIPs itself presents to end users like broken software. Why does it work in Damus but not Amethyst? Why does it work in Amethyst but not Coracle? That is an even harder problem to solve.

But let's at least solve the easier problem and stop changing NIPs. If you don't like a NIP make a new one, don't break the current one. Even if you think the current one sucks balls and should have never happened. Even if you think there aren't many implementations out there.

Actually I am not aware of these breaking changes. And I develop a client too… what are you referring to?

Good news: Working on adding nostr-connect to cashu-address-cli for v0.2

What implementation of nostr-connect are you using if you don’t mind me asking?

Oh so Alby now detects when a website wants to do nip-07 stuff and ask the user to setup keys? That’s interesting! I will look into this.

You will however need an NIP 07 provider or use the CLI. I am working on more clients to interact with npub.cash as we speak

Weekend Update 🔥

npub.cash aliases are now nip-05 identifiers too 💜 thanks for nostr:npub1q7why7lw8kq9ufr43ps75ngz3vhx5duqt7xmgklcq3dljqqfjegq2km2vr for the amazing suggestion!

Now you don't need to have two different addresses in your profile anymore :D

Did something go wrong with NIP-07? Does refreshing help? Unable to get balance can mean many things. Browser console should give you a proper error code