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.
I'm not saying tha REST is the right way to go. Just that it would be nice if a client to request POW (over a websocket is fine) without having to implement the auth nip.
And I can't imagine how a deep dependency graph could ever be a good thing. Modularity is one of the most important principles of design. You should be able to pick and chose which nips you implement without having to parse through a tree of interdependencies.
I should add, I love the nip otherwise great work!
Thread collapsed
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.
Thread collapsed
Thread collapsed
