Ohhhh! Can not wait to hear your verdict
I finally made it. npubcash-server is now deployable without much hassle. 🥜
This is not final and merged yet, so please proceed with caution. If you try it out, please let me know when you break something 💜🙌🏻 nostr:note1fs4fchm4dwaadj5w76yqmc6uxm4zfmamms8grf369sdaydqul25sh4wqmk
Getting there 🫡 
nostr:note1e97ep3efx2hkx52zf06krp7hkddyszm8hntypnahcwm39vjxzmaqrff877
It's going to be a loooong day...
nostr:note1e97ep3efx2hkx52zf06krp7hkddyszm8hntypnahcwm39vjxzmaqrff877
It's going to be a loooong day...
nostr:note1e97ep3efx2hkx52zf06krp7hkddyszm8hntypnahcwm39vjxzmaqrff877
By the end of today npub.cash will have close to full test coverage and be deployable by anyone that has a Blink account.
Diamonds are made under pressure 💎
Tricky… I am not sure if using a nostr key instead of a session token is a good idea, as it would need to be inherently less secure.
A session token can be a http only cookie, while a nostr key would need to be accessible to JavaScript in order to be useful, making it vulnerable to XSS.
If this leads to the conclusion that a session token shall be used, then a NIP doesn’t make sense either, as it’s not really a nostr centric thing anymore.
No, unfortunately not. This works only for apps that are independent from the nostr protocol because the session token can not be used to sign nostr events.
Its only useful for authentication
⚡We've added Lightning invoice decoder to Amboss Space!
Invoice decoders deliver insights about payment requests that can come in the form of an invoice, an LNURL, or a Lightning Address.
To demonstrate the insights you can derive, we've prepared a thread of wallet invoices!
Starting simple, here an invoice from BitcoinJungleCR, a custodial lightning wallet:
Similar setups include: zbd, walletofsatoshi , and Strike
This is a BOLT11 invoice where it pays to a single node destination. Routing Node Operators will use the Payee Pubkey information to discover new nodes to connect to so that the network can have a variety of routes to pay BTC Jungle CR reliably.
https://amboss.space/node/03797da684da0b6de8a813f9d7ebb0412c5d7504619b3fa5255861b991a7f86960
Next up in complexity, a BOLT11 invoice from @Breez_Tech, a self-custodial lightning wallet:
If you check the Payee Pubkey of the Breez invoice, you'll reach a page that says "Unable to find this node". This isn't a error; this reveals that @Breez_Tech is using "private" node destinations.
To help the lightning payment reach the destination, it will require Route Hints!
In the Routing Info is a Pubkey, revealing a well-connected 28 BTC capacity node that will convey the payment to the "private" node destination.
Services with similar setups include: MuunWallet (uses a swap service), ElectrumWallet (yes they do lightning!)
"Private node" here only means unannounced to the network (like not listed in the phone book), not a guarantee of privacy.
There are many reasons to use private nodes in practice and most of them are operational: load balancing, payment reliability, failover protection, etc.
Even more complex, we have @CashApp invoices, which include 2 separate paths to reach a private node destination. https://amboss.space/lightning-decoder?request=lnbc1pnxrdk6dqdgdshx6pqg9c8qpp59d8cvaf5209myfkn9wk67ywa5exyt230gjpkjs7dh0yxzczaqk4ssp5e8e6wehwurw4zdfs6lkj5s9my702vpxjs26zfyv3vmrw00x64k0q9qrsgqcqpcxqy8ayqrzjqv06k0m23t593pngl0jt7n9wznp64fqngvctz7vts8nq4tukvtljqz3rvvqq88sqqsqqqqqqqqqqqqqq9grzjqtsjy9p55gdceevp36fvdmrkxqvzfhy8ak2tgc5zgtjtra9xlaz97pmylyqqt0gqquqqqqqqqqqqqqqq9gwmef3kht3jvnnft2yqagtdr6qsp0mw00mcs334wmjakjxf7m0suy3dm0cjcr9vd03c500225tf4suxu9ufrsqrl2p3k748ctvlygm3cpcr888n
Instead of only one potential path to pay, there are now two which can be attempted. This allows one of the public nodes to undergo maintenance while the other remains online to ensure higher payment reliability.
Makes sense when you have 50 million potential users!
Okay now it gets crazy complex: @fedibtc Bravo includes not only two separate routing paths, but there are multiple hops in the second path!
Look how long the invoice string is! That is a lot of data to pack into an invoice, which can also make the invoices more difficult to scan as QR codes or be unable to fit into a tweet!
Setups like this one are fascinating, but each decision is a tradeoff.
In the 2-hop path, the first stop is @LQWDTech followed by "Henwen 🐷", which was also used in the 1-hop path.
This must make Henwen one of the "Gateways" into the ecash Federation.
https://amboss.space/node/0364913d18a19c671bb36dd04d6ad5be0fe8f2894314c36a9db3f03c2d414907e1
https://amboss.space/node/02f0c7b731ca40a285d7c12aa1c5c7c7caa4598d3d6d34904c3714cd0d47852640
Mind blower time. Let's talk about @AquaBitcoin invoices.
Aqua invoices only include a single route hint, but the route hint is to a private node!
The payee pubkey is a public node, @Boltzhq, which swaps between the @lightning network and @Liquid_BTC.
Boltz is using "magic routing hints" allowing Liquid to Liquid payments within LN.
https://docs.boltz.exchange/v/api/magic-routing-hints
We hope you learned a lot from this thread!
What else would you like to know about invoices?
What other insights can you gain from this tool?
Is the decoding done on the client side? Did you write a tool for it or is it based on lightweight-bolt11-decoder?
If you did write a tool for it, is it open source and typed?
I have got about a gazillion projects that could use that lmao
Thanks to nostr:npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4s calling me out on the ease of use of npub.cash, I am working on a OTP type login.
The user will enter their pubkey to login. The server generates an one-time-password and send it to this pubkey in an encrypted DM. The user can then enter the OTP in the browser window and obtain a session token.
This will dramatically increase the UX on mobile devices and offer a more sure way to login vs. raw nsec.
Oh I like that… an OTP that’s sent by the service via DM and that then can be used to create an authed session.
It’s less secure than the current system, but I guess that can be mitigated by requiring 2FA or something.
Yes. Though there are things to consider. What’s about change, what’s about P2PK locked balance?
An API via DM is a low hanging fruit, especially to just get the token out. But full “wallet” support is probably infeasible (at least once P2PK is enabled for all users)
Server can keep track of ids and disallow timestamps that are out of bounds. No need for a challenge
nostr:npub1mhcr4j594hsrnen594d7700n2t03n8gdx83zhxzculk6sh9nhwlq7uc226, nostr:npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4s has a brilliant idea here btw: DMing the service could also be used to initiate a withdrawal.
Wow! That really is brilliant nostr:npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4s!
This will definitely get integrated 🙌🏻
Lmao, point taken. Although I try to keep it that way at least 80% of the time. Clutter keeps me from concentrating