Here is an rust Nostr Paywall example project. It responds with 402 Payment Required, unless your NIP-98 HTTP Auth event’s pubkey has been granted access.
https://github.com/blakejakopovic/nostr_paywall_example
It’s a separate project, however it can work together with the lightning payment webhook server I shared yesterday. Payment webhook events can update the DB, and then the paywall can succeed, and provide access for that pubkey for that content.
cool
#[1] I purposefully left out the 402 payment required response for now. Ideally it returns an invoice to be paid (maybe in the header?). I also left out the invoice metadata for referencing pubkey and content/item - however that can ideally be solution agnostic.
Ideally we can standardise this, so Nostr client apps can get a 402 for content, with a payable invoice link, and then optionally make a payment (like a zap). And some way for the client app to refresh or reload the content.
#[2] happy to work with you and hear your thoughts on how this can be work best for Nostr client apps. I’m hoping these projects can be part of the foundation pieces for this (very early) draft NIP for Nostr Paid Services and their management.
Ideally Nostr feeds aren’t just walls of content requiring payment.. however I think we can define a way to filter it. And it can enable services too like translation or paid bots, etc.
https://gist.github.com/blakejakopovic/a0deee4c945c122a59ed2dcf442d2e2a
I love your work. It has the potential to be the foundation of something very big. If done properly, it could be a great tool for creators to monetize their work.
This model works, I have seen its potential.
Yep. I’m following your awesome efforts too. I think monetising for creators is incredibly important to bring large communities over to Nostr.
I’m excited by how this can be used for Nostr shops too. Subscriptions, buying credits, and buying goods (specifically digital for now).
The paywall (maybe a bad name really.. it’s just a payment validation server) shows invoices, then users pay them, then the webhook updates the DB to grant access and maybe send confirmation, and then the paywall server now allows access to the content.
Ideally we support non-custodial with first class, however even something custodial with maybe splits or invoice wrapping could work. It means providers can get paid for the platform, and content providers get paid too. However self-hosting is also an option.
The marketplace and subscription platform is a very interesting area, as it can be very sophisticated, but at the same time, we can also have a simpler version.
I am planning to offer users a marketplace connected to the Zapit wallet with Lnbits as the backend. With this, creators will have their proper dashboard for managing products and a good showcase webpage,
while buyers can make payments with their address, email, or public key.
Here is an example: https://pay.zapit.live/market/stalls/HJASfmLpxmFEV8vZ2pQGQC
Worth noting too that this project doesn’t actually require the access to be paid. It could return 401 Unauthorised instead of 402 Payment Required, if access is whitelisted for example.
It could be used to check a pubkey against premium relay membership for extra services, for things like accessing your own backups, uploading media, or translation, etc. Basically any Nostr HTTP Auth scenarios.
And it’s written as middleware, so you can use it as a rust library/crate in your project.
