Avatar
Blake 2y ago

I’ve written two basic example rust projects that I’ll try open source this week.

1. BTCPay server webhook that can update a database on invoice payment.

2. Nostr 402 Payment Required paywall server that uses NIP-98 HTTP Auth after payment to authorise access. It likely can generate lightning invoices before payment too.

The basic idea is that if you ZAP or pay an invoice, the same URL can return the desired content if you sign a Nostr message that proves your private key which can be used to check prior payment.

Ideally we can support some kind of Nostr client app UX, where content can refresh post-payment.

Reply to this note

Please Login to reply.

Discussion

Avatar
Kieran 2y ago

I will be building #2 into snort this week maybe if I don't get distracted

Avatar
Kieran 2y ago

Void.cat I mean

Avatar
Blake 2y ago

Happy to collaborate - or at least make sure it’s compatible.

Did you have a plan for invoice generation? Generate new invoice per 402/Content? I’d like to support ZAPs and be non-custodial ideally. I thought about supporting inbound webhook a from users local lightning nodes - basically they forward payment success messages which unlocks the content.

I have a concern around privacy - because you leak the pubkey - and ideally you’d only want to provide a pubkey if you’re paying or think you’ve paid.

Avatar
Kieran 2y ago

I'm using hold invoices on my LND node, to proxy invoice payments to any LNURL

Avatar
PABLOF7z 2y ago

I at the same time get excited when I see someone using hodl invoices, for the experimentation, but also sad, because of how bad hodl invoices are for lightning 😅

Avatar
Blake 2y ago

Once Nostr matures a little, the Nostr devs may need to help the lightning devs for a bit. Seems like lightning is a bottleneck for lots of cool stuff.

Hard problems to solve for sure, but with devs and momentum of real world use cases that Nostr can bring to life, I can see it working.

Avatar
Kieran 2y ago

Bad why? It's only bad if they get stuck

Avatar
PABLOF7z 2y ago

yeah, tying liquidity across the entire route; by their very definition they are htlcs you don't want to immediately settle; short duration hodls are not problematic, but multi-hour/day ones... 😕

Avatar
Blake 2y ago

Have you seen this?

https://lnproxy.org/about.html

Avatar
Kieran 2y ago

Yea it works exactly like LNProxy, my kieran@snort.social LN address is using it right now

Avatar
bumi 2y ago

this is super cool!

fyi: we hat this SoB project: https://blog.getalby.com/building-a-content-distribution-proxy-implementing-the-lsats-spec/

using lnurl + lsat

and there is: https://docs.ocps.tech

Avatar
Tony 2y ago

Bookmarked for reading first thing tomorrow

Avatar
Blake 2y ago

Nice. So we have some prior art. I’ll have a detailed look.

Avatar
Kieran 2y ago

Cool, i was probably going to follow LSAT, or just use Nostr HTTP auth, didnt decide yet

Avatar
PABLOF7z 2y ago

Hahahhaha

“if I don’t get distracted”

The story of nostr devs

Avatar
PABLOF7z 2y ago

The struggle is real

Avatar
Vanessa 2y ago

Indeed lol

Avatar
0xtr 2y ago

👀🚀

Avatar
bumi 2y ago

sounds awesome, are you aware of the lsat spec?

Avatar
Blake 2y ago

I need to look into it again. I’ve become more of a user than a dev in the lightning world.

Avatar
Tony 2y ago

This is 🔥

Do u think you could also enable a “crowd wall”, where if the desired amount is reached, content becomes available for anyone?

Avatar
Blake 2y ago

That’s certainly possible. I’m trying to make it generic so far; logic around minimum fee or minimum total to unlock, and who gets access once unlocked, etc, can be separate logic. Ideally it would be easy as sending a ZAP.

I’ve also tried to keep it content hosting agnostic. In theory it could proxy the media from somewhere else.

My biggest hurdle is maximising privacy and ideally having it non-custodial end to end. And other stuff I don’t have a clear design for.