Sure. I’m not pro coupling code or dependencies.
If the only change is a pubkey added to the minimal request, we can do that.
However, keep in mind the request itself [“POW”, {}] is like other Nostr relay commands anyway. If you wanted different format for that too, then we start to diverge into really different approaches.
I’m not running a PoWSP, even using my codebase. I put this together mostly as protection if we need something urgently for spam or similar attacks. We have time to experiment - we need clients first anyway.
It’s my NostrGraph public relay backend, but internal dashboards.
I keep trying to find a way to make them public. It’s just a lot of time and it would need to have a cost. 
Interesting approach. If encrypted as a DM it could self destruct on first fetch.
No solution will be ever copy or persistence free. Always a risk or opportunity to skip, defer or prevent remote deletion.
The issue is a REST service is not ideal as clients are already connected to at least one websocket. And the POW can take seconds to return a result. Since websockets make sense, using the auth NIP made sense too - as clients already support it (or will soon).
The idea was it can be run independently from a relays or a relay could enable the POW command optionally - using a supported nip in their server info.
Relays are the closest next step for events that have had POW/signed.. so it made sense to keep them together or very close.
The POW nip already explains the basics to add POW, so this was more of a NIP for a provider that had opinionated design.
There is also a growing dependency graph of NiPs that build on other nips. I see it as good thing, but it does make it harder to start from scratch.
Using images? What are you working on?
My first deletion events. 
My evil twin. We finally meet 😄
It’s a good point. The minimal spec was to use less data and since it relies on the AUTH NIP, we already know the pubkey.
I’d imagine someone could want someone else to request generation of POW for one of their events and then get them to sign it. But why have a middle man?
The assumption is the requestor holds the secret key for the pubkey of the events they are asking for POW generation for.
Secondly, since it’s expected this would never be a free service, the pubkey would be the member or account holder or account to be charged/deducted from.
Open to suggestions if pubkey is needed.
A nice little service could be a notification via DM when your profile changes - specifically any Bitcoin/Zap related values.
Basically a honey pot to detect stolen keys. Or confirmation when it’s been changed by you.
Tagging a few people who showed interest.
And thanks for the zaps :)
#[1]
#[2]
#[3]
#[4]
#[5]
#[6]
#[7]
#[8]
#[9]
#[10]
#[11]
#[12]
Ok, so I found a way to finish this today and push a functional beta version live.
Nostr Event Deletion Webapp.
It can’t really cause any bad side effects - just read before you sign and only enter event ids you want to delete. You can only delete your own events.. relays will reject deletion request for events you don’t own.
I’ll publish the code formally after I can clean it up (it’s ugly) - however, you can just save the HTML and it includes everything.
It’s actually fully functional apart from the decode note1, nprofile1 and naddr1 codes back into the raw hex event id.
Yep. Will be free and open sourced. Ideally as a single static webpage with a couple dependencies loaded from a CDN.
#[0] I’m working on this bounty. https://nostrbounties.com/b/naddr1qq9rzd3h8y6rswfsxyuqygpm7rrrljungc6q0tuh5hj7ue863q73qlheu4vywtzwhx42a7j9n5psgqqqw4rsx4q2ka
Can you explain what breaks?
It’s not ideal, but perhaps to help access to Nostr in China we can data dump new events (db exports) daily somewhere. They could hydrate on their end. Compressed I think it’s only 200mb day.
Yeah. Using Damus. Tried Post and profile zap buttons.