Basically before the event is signed (the sig key), the event id key gets generated.
I wrote the service as a websocket server, and something even relays could directly support and get paid for each generation or use a paid credit system.
Basically before you post you pick a POW provider, send your event and a minimum POW you want, and if you have credits, it will return an event that’s ready to sign and then publish.
All Nostr clients support websockets. And all clients that can sign, already generate the event id and sign the event - using this service just deferred the event id generation to a remote service provider, before the signing.
If you’re interested in Clojure, or even just system design and data structures - the latest Clojure Conj 2023 videos are being uploaded to https://www.youtube.com/@ClojureTV/videos
When I first found Ruby, it became my first favourite language. I eventually tried lisp and Clojure/ClojureScript and was like 👀. This is awesome (and (a little) weird)!
Today I prefer to upset #[0] and use rust. I have no favourite languages today.. most serve a purpose, but some make you a better engineer.
And my final point..
If there isn’t much interest, I’ll close the GitHub issue in a week or so - as it’s served it’s purpose for now.
If anyone is interested in Nostr Proof of Work, I have a draft NIP and functional implementation of a POW service provider that can remotely generate POW for your events before signing and publishing.
The general feedback and support was on Nostr, and the Github issue responses were more concerned based.
I built this entirely in anticipation for mass Nostr spam protection - in case we needed it urgently. We seem to be doing ok with spam now, however it’s possible we may need to revisit minimum POW for events when publishing - as a relay opt-in.
And just to clarify, I don’t like burnt CPU cycles either. Paying sats directly to a relay works well - however unless you pay for 10+ relays.. your events are not decentralised (as most relays move toward becoming paid to publish). POW helps address the issue of low value spam and flooding - it doesn’t solve everything.
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.
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.
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.
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.
#[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
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.
A fair few apps now support the AUTH NIP, so it can be removed from the end.
Still need more app support however.
This is why we need to ensure the censorship resistance properties of Nostr don’t erode as a critical priority. I don’t care if Google or Brazil gov is right.. the fact conflicting information can exist is the very core of freedom of information.
Decentralised moderation sounds fun and all, until it’s used by the state against the people. Moderation for small, centralised circles is fine. We need to take care with how we approach it.
We also need to ensure relays remain as dumb and generic as possible - as a general service. And avoiding storing media and files directly on relays (unless you choose to separately). Certainly we can build apps and experiences on top - we just need an enduring base network layer.
And as a side note, seeking freedom of information isn’t promoting hate speech or bigotry or whatever I’ve seen said recently. It’s about having access to self-informed choice when it matters - because one day the government will turn on you too. Doesn’t matter if it’s extending your retirement age, giving you a social credit score, forcing you to stay locked inside, or sneaky new taxes and privacy eroding laws.
Long Live #Nostr nostr:note1ec055mlu4klct22sy6rd89fcd93s5h0ntlxzrp6ageuqdztwml7q7dcn79
I’ve published my rust BTCPay and LNbits webhook library with example projects for each platform. The code is really simple to follow.
This means when invoices are paid, you can trigger actions, like updating a database to grant access to a pubkey (like a paywall), add credits to an account, sending a Nostr message, or whatever. It performs the HMAC validation for BTCPay server payloads.
I’m not using it yet myself, as I need to finish my Nostr Paywall Server project first - which I’ll release this week. Let me know if you’re keen to use it in production or any other features needed.
Great podcast with #[0] by #[1] - Why deflation is the key to abundance. Thanks #[2].
nostr:note154xfz4u5h58pkk5x87x5f8jjhdttfefm64p5f9n8xrnfhy60uv9qzjzv7t
A way to leave and read reviews for relays before joining would be cool..
Agreed. It’s easy enough to support payment options.
I bought an official Boostrap Theme for NostrGraph. Haven’t implemented it yet, as it’s raw HTML and not components. Maybe I use something else.
A template is definitely a solid way to get something looking good and functional quicker.. plus I find web UI tedious.
https://themes.getbootstrap.com/product/phoenix-admin-dashboard-webapp-template/
Should there be a profile tab to show what events someone has zapped? Could be cool.
Thanks for welcoming all the newbies! You’re de-confusing a lot of souls who adventure into the World Wide Nostr (WWN).
Location based groups, like city or town, are something people always like to join. Definitely something missing today from Nostr. I’ve wondered who is using Nostr in the cities I’ve traveled through the past year.. asking and hoping you’re seen in global chat isn’t exactly effective today.
And often the location based groups are hybrid physical good / rental marketplaces too. All possible on Nostr.