Nostr Web Client

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.

https://github.com/nostr-protocol/nips/issues/340

Veil 2y ago

I think this idea has merit.

Would the idea be that the service provider receives the event, then responds back with a nonce the may be used to meet the difficulty?

Or would it be more involved in the signing than that?

Reply to this note

Please Login to reply.

Discussion

Blake 2y ago

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.

Veil 2y ago

Curious how you see the credit system working. Is it based on the author of the event or would it use client auth? 🤔

Blake 2y ago

There is a relay AUTH NIP 42 as well, so basically my pow service example only lets you request events with your pubkey to have pow generated for them. That means someone else can’t use all your credits by pretending to make events from you, and it means you can deduct credits or have a fee you can drawn down for that pubkey.

These projects are all related and can work together. I don’t want to tell people how to charge or do accounting - even if they wanted to accept fiat. I’m focused on Bitcoin and lightning however, and bringing the tools we have up to scratch to empower providers.

nostr:note1u0pxa5egj4258f84hp75jl65d9ldh3a63l87du7gnk7cs00nkxzqtpltmv

Mazin 2y ago

Cool stuff as usual Blake, thanks for sharing.

Blake 2y ago

Let me know if these projects can help you with real world outcomes. I’m mostly slowly building for myself and the ecosystem - but the reality is we don’t have that many Nostr rust devs.. so often it feels like other people using stuff has a low chance atm.

I’d love to build on top of these projects and end up with more full functional projects people can use and run themselves. Like even a nice way for paid relays to not rely on third parties they don’t want to.

Mazin 2y ago

Appreciate that and I certainly will. Most excited about the http auth as that will be helpful in multiple ways.

Will be watching PoW space in the future.

Veil 2y ago

I suppose I could also just wait for the draft proposal 🤣

Blake 2y ago

There is a full draft NIP written up as well.

https://github.com/blakejakopovic/nostr_pow_service/blob/master/NIP-XX.md