😆

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

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.

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

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.

Have you seen this?

https://lnproxy.org/about.html

Another nice open source Nostr Event signing and Delegation web app, nice for tinkering - authored by #[0]

https://nostrtool.com

SuperTestNet has build some awesome Nostr stuff. Still can’t find their Nostr pubkey 😅

Ha. That was my strategy..

But then I found out that BTCPay has a testnet lightning demo instance. And then HTLC.me payments worked fine. Which is enough for me to learn and test things end to end for now.

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.

https://HTLC.me is an awesome testnet Lightning wallet for playing with test invoices.

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.

Maybe it could expose a webhook a LN server can post to.

I’m building a BTCPay server webhook handler as well.. got stuck, but found how to progress it again earlier today. Basically it can execute any SQL on successful payment.

I’m mocking up a web server in rust that could be used for this. Unsure how to verify payments without holding funds, but otherwise it can manage the requests and handle the pubkey auth. I’ll open source if I get it functional.

nostr:note1q9e3kjuqk8fynx3h2qs65q0dx90w447kd3zue7zwnjfr2fglg9dqpj9wev

I think the lines of optional get blurred when someone else can break your app and user experience.

At best, it can be a simple few lines code to filter or add support, at worst, it’s indistinguishable from existing content and there isn’t an easy way to gracefully ignore it - or people perceive it as censorship because they didn’t see it.

Decentralisation is a blessing and a curse. Is still prefer to have it than not.

Of which in particular?

The simplest example that comes to mind is IP address leakage, VPNs and geo-blocking. Tor for example leverages the school of fish analogy.

Another example is the Tornado Cash transaction banning. Tying metadata to transactions makes them a target for censorship.

Kind 1063 seems ok, as it’s basically like a mapping or lookup metadata event. It’s not designed to store data, but basic properties and how to fetch it elsewhere.

However kind 1064 storing files on relays is a bad architectural approach for a few reasons.

1. Events are stored in DBs today. DBs hate binary (in general). We have enough text based data to try make fast and efficient - especially when we 10-1000X.

2. Relays need to be lighter weight to minimise the cost of running them.

3. We don’t want to encourage the vector of DDOS or fill relays disk space denial of service attacks. Or even promote storing encrypted blobs of file chunks - like in DMs.

4. We need a general purpose distributed and decentralised file storage system anyway - Nostr can piggy back off it when we solve that problem.

5. Files create more attention for geographical regulation. Hosting issues. Vector of DCMA fraud. Etc.

The main issue today is client compatibility and breaking user experiences - with something that common sense tells us cannot scale or function as intended.

#[0]​ what would be really cool is a way to optionally auto-refresh an event’s embedded media after a zap has been paid - maybe with a minimum sat.

Would be nice to use the same URL, that returns 402s without payment, and likely a blurhash, but 200s after zap. Maybe the post-payment requests includes a NIP 98 header for auth.

Main risk is privacy around sending your pubkey for all media requests because you don’t know if you’ve already paid (before first http request) - and that’s a privacy/tracking vector.

Ideally private zaps could unlock content too.

https://github.com/nostr-protocol/nips/blob/af4cbfbddb2900b7bc4a56b57430989e8b613006/98.md

I don’t have an M1/2 Mac, which I suspect is the issue in my case.

For maximum censorship resistance, you want to be a fish in a school of fish - very hard to isolate and eat.

Adding fine-grained (often ‘controversial’) metadata to single you out, makes you, and those who interact a target.